Internet Draft David Durham
Expiration: December 2000 Hormuzd Khosravi
File: draft-durham-aaa-cops-ext-00.txt Intel
Walter Weiss
Lucent
Avri Doria
Nokia
COPS Usage for AAA
Last Updated: May 31, 2000
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC-2119].
Durham et al. [Page 1]
Internet Draft COPS Usage for AAA June 2000
Status of this Memo................................................1
Conventions used in this document..................................1
Abstract...........................................................3
1. Introduction....................................................3
1.1 COPS-AAA Model:................................................4
1.2 Information Model:.............................................5
2. COPS Broker/Proxy Support.......................................7
3. COPS Specific Object Formats....................................9
3.1 Context Object (Context).......................................9
3.2 Decision Object (Decision).....................................9
3.3 Error Object (Error)..........................................10
3.4 Client Specific Information Object (ClientSI).................10
3.5 Report-Type Object (Report-Type)..............................11
3.6 PDP Redirect Address (PDPRedirAddr)...........................11
3.7 Last PDP Address (LastPDPAddr)................................11
6. Security Considerations........................................13
7. IANA Considerations............................................14
8. References.....................................................15
9. Author Information and Acknowledgments.........................15
Durham et al. Expires December 2000 [Page 2]
Internet Draft COPS Usage for AAA June 2000
Abstract
This document describes how COPS can be used as a general purpose
Authentication, Authorization, and Accounting (AAA) Protocol.
1. Introduction
This document describes how the COPS model can be extended from the
client-server query-response usage to a brokered or proxied model as
well. The basic model of interaction between a policy server and its
clients is described within the framework document for policy based
admission control [WRK].
A chief objective of policy control protocol is to begin with a
simple but extensible design. The key features of COPS that are
useful for the AAA Framework are as follows:
1. Simple, Lightweight Design: COPS is designed as a simple
client/server protocol. It is thus lightweight and is very
easy to implement.
2. Reliability: COPS uses TCP as its transport protocol for
reliable exchange of messages between clients and a server.
Therefore, no additional mechanisms are necessary for reliable
communication. Other reliable transport protocols can also be
used to carry COPS messages as the protocol is defined
independently from the underlying transport.
3. Extensibility: The protocol is extensible in two ways. One,
it is designed to leverage off self-identifying objects and can
support diverse client specific information without requiring
modifications to the COPS protocol itself. Two, the provisioning
extensions define a generalized mechanism for communicating
well-defined data between the client and server for the general
administration, configuration, and enforcement of policies
whether signaled or provisioned. Thus, the protocol may be
extended for the administration of a variety of signaling
protocols as well as the configuration of a device.
4. Security: COPS provides three security mechanisms. First,
COPS directly provides message level security for
authentication, replay protection, and message integrity common
to all COPS implementations. COPS can also reuse existing
protocols for security such as IPSEC [IPSEC] or TLS [COPSTLS] to
authenticate and secure the communication between the PEP and
the PDP. Finally, COPS can carry CMS [COPSCMS] enveloped objects
for end-to-end confidentiality, integrity, and non-repudiation.
5. Stateful Model: Clients are able to instantiate state within
their server corresponding to their requests, and the client may
Durham et al. Expires December 2000 [Page 3]
Internet Draft COPS Usage for AAA June 2000
update or remove this state at any time. Additionally, the
protocol is stateful in that it allows the server to respond to
such requests with a decision or directive, and allows the
server to change its decisions at any time while the state
remains installed.
6. Fail Over: COPS provides a fast failover mechanism. It
essentially uses keep-alive messages between the client and
server to verify the connection. When a failure is detected, the
client must try to reconnect to the remote server or attempt to
connect to a backup/alternative server. Once a connection is
reestablished, the internal state of the client can be
resynchronized with the server only if needed.
1.1 COPS-AAA Model:
The COPS protocol supports two common models for policy control:
Outsourcing and Provisioning. The Outsourcing Model is client
driven where the client requests authorization from a remote
server. COPS-PR [COPSPR] or the Provisioning Model is used by
the client to request that the policy server proactively
provision the policy client with its directives. Provisioning
refers to the ability to issue directives to a device in a
stateful manner such that each directive can be monitored,
updated, or withdrawn as appropriate to the situation.
Outsourcing refers to the ability of the client to issue
multiple requests to receive authorization to use network
resources or services and/or authenticate itself or a user. In
the AAA model, COPS clients make one or more requests to their
servers using COPS-PR defined data, and servers likewise respond
with COPS-PR defined decisions depending on the type of request.
The COPS-PR Model is very suitable for the AAA framework. One of
the main advantages that COPS-PR has is that it decouples the
Information or Data Model from the protocol. For Example, COPS-
PR uses PIBs or Policy Information Bases that define the
Information Model for QoS Policy Provisioning among others. PIB
data can be used to specify the information used by a client in
its requests and accounting reports as well as by a server in
its decisions. This makes the Model extensible and very flexible
while using structured data. COPS supports the different COPS-PR
client-types as non-overlapping and independent namespaces.
Thus, the Information Model can be defined for different areas
of policy provisioning (e.g. security) and authorization (e.g.
NAS-AAA) while sharing the same underlying COPS protocol.
In COPS, each request-state identified by the COPS client-handle
corresponds to an individual AAA session. As each client-handle
in the COPS-PR model represents a non-overlapping and
independent namespace, each session can be dealt with
independently.
Durham et al. Expires December 2000 [Page 4]
Internet Draft COPS Usage for AAA June 2000
There are also many instances where AAA clients defer to servers
for decision support, or for requesting the additional
information necessary for completing a process such as a dialup
access request (login). In these scenarios, COPS is ideally
suited for this paradigm, particularly since COPS was initially
designed to meet this specific objective. No only can it provide
Yes/No decisions to client requests, using its Information
Model, sophisticated directives can be issued (such as allow
access but only for 30 minutes, or specify the list of services
available to the user).
1.2 Information Model:
An Information Model is a formalization of the data structures
used to configure and manage network services, request access to
services, and report service activity. Information Models have
their origins in OO design and take advantage of all the
capabilities inherent to Object Oriented principles. Of the
capabilities provided within the OO framework, those most
relevant to any AAA protocol (and COPS in particular) are
inheritance, containment, and associations.
Inheritance and containment both provide a means for reusing
various data structures. Inheritance provides the means for
sharing those attributes common to many components while also
allowing for the refinement of management interfaces that are
specific to a given implementation. In some sense, inheritance
is another way of expressing specific refinements or extensions.
Consider, for example, those attributes common to all
authentication protocols. These attributes would be specified in
the AuthenticationService class that forms the root for all
authentication related management interfaces. This class may be
refined (derived) in two peer classes: PapAuthenticationService
and ChapAuthenticationService. Both derived classes include all
the attributes defined in the AuthenticationService class.
However, the ChapAuthenticationService class differs from the
PapAuthentication class with respect to the PAP or CHAP specific
attributes. The PAP class may, in turn, be derived to specify
vendor or product specific extensions to PAP. The result is a
tree of class definitions with very common, but very abstract
interface attributes at the root of the tree and very
implementation specific attributes at the leaves of the tree.
This ability to add refinement within a hierarchy of
abstractions makes interface management far more flexible than
it is with current management structure definitions while
maintaining interoperability. When advances in authentication
technologies occur, the tree can be extended at the root, the
limbs or the leaves of the tree depending on the degree to which
these new technologies are different from those already defined.
Durham et al. Expires December 2000 [Page 5]
Internet Draft COPS Usage for AAA June 2000
Containment refers to the ability to embed specific types of
structures within other structures. One could consider
containment the ability to embed new complex data types within a
class. Containment is similar to Hierarchies/Derivations in that
the attributes of a contained class and superclass (parent of
the hierarchy) both have the same life span as the attributes in
the container or subclass. However, the difference between
containment and inheritance is that a contained class reuses an
unrelated data structure while an inherited class is a
refinement of a related data structure. To continue the previous
example, a PAP or CHAP class may contain an IP address class
that describes the characteristics of an IP address (the mask,
the class, whether it is multicast, etc.) Clearly an IP address
is not a refinement of an AuthenticationService. However it is a
complex or reusable structure that may be necessary to describe
the AuthenticationService.
Associations represent the relationships between various
independent structures. Unlike container class instances, which
only exist as long as the contained class instance, associatied
classes can exist independently of each other. For example, an
IP address specified in an AuthenticationService is only
relevant as long as an instance of the AuthenticatoinService
exists. However, a user using the AthenticationService can exist
irrespective of whether the AuthenticationService is active or
not. Therefore, if it is appropriate to bind an
AuthenticationService to a User, an association is the most
appropriate means for capturing this relationship. Note that
while associations are not necessary to any single transaction,
it is potentially relevant to determining related, subsequent
transactions. The scenarios for using associations are
comparable to those that use RowPointers in MIBs.
Reusability is a key element to an Information Model. The
ability to define a User that is consistent not only within a
space like AAA, but also Security, QoS, address management, to
name a few, is critical to the consistent administration of
users and ability to allow various technologies such as AAA and
QoS to operate collaboratively.
The Information or Data Model that is used with COPS-PR supports
the AAA framework. The concept of a data model is a common data
representation that fully describes a given set of standard AAA
data structures and relationships. As additional data can be
described using the underlying data representation, extensions
to the data model are simple to add. Fundamentally, three sets
of class namespaces can be defined for Authentication,
Authorization and Accounting respectively. The existing work
done in defining Accounting Attributes can be used to define the
accounting Model. The NASREQ, ROAMOPS and MOBILEIP working
groups can jointly define their respective parts of the Model,
such that it satisfies all of their data model requirements.
Durham et al. Expires December 2000 [Page 6]
Internet Draft COPS Usage for AAA June 2000
COPS simply provides the reliable transport semantics (Request,
Decision, Report) and security mechanisms (native, TLS, and CMS)
for communicating these respective parts of the model.
The Policy Information Base or PIB which is used for QoS Policy
Provisioning uses SMI [V2SMI] for its data representation
language and BER [BER] for data encoding. These useful
mechanisms were adopted so that the experience, tools and code
from the network management community can be reused. A similar
approach can be used for the AAA framework but this is
definitely not a restriction. COPS-PR supports different
encoding schemes, for example XML string based encoding, by
using the S-Type field in the COPS-PR protocol objects.
Additionally, support for using the ADIF[] format within the
encapsulating COPS base protocol objects can be defined as well
as RADIUS AVPs among others as is appropriate for AAA.
2. COPS Broker/Proxy Support
COPS can support both the different types of brokers mentioned in
the AAA framework i.e. Proxy Broker and Routing Broker.
Proxy Broker:
+--------------+ +--------------+ +--------------+
| | | | | |
| Local AAA | | Proxy | | Home AAA |
| Server | | Broker | | Server |
| | | | | |
| +------+ | COPS | +------+ | | |
| |Client|<--|------|-->|Server| | | |
| +------+ | | +------+ | | |
| | | ^ | | |
| | | | | | |
| | | | | | |
| | | v | | |
| | | +------+ |COPS | +------+ |
| | | |Client|<--|-----|-->|Server| |
| | | +------+ | | +------+ |
| | | | | |
+--------------+ +--------------+ +--------------+
Figure 1: A COPS Proxy illustration.
A COPS Proxy Broker is similar to a transparent proxy and
essentially performs routing functions. As shown in Figure 1,
the proxy broker forwards a COPS Request from the Local AAA
Server to the Home AAA server. It acts as the COPS Server to
receive the request at the Local Server and as the COPS Client
to send the request to the Home Server.
Durham et al. Expires December 2000 [Page 7]
Internet Draft COPS Usage for AAA June 2000
It can also act like the LDP i.e. local decision point.
The Proxy Broker can perform authentication for the COPS Request
from the local server based on local policies. It can reject the
request and send a COPS Decision message with the appropriate
Error Object. The use of Proxy brokers reduces the amount of
configuration information maintained on the AAA servers.
Information from the client that is intended for the home server
only or information from the home domain intended for the client
can be protected using CMS. CMS provides end-to-end security by
protecting the COPS-PR objects within a COPS message. CMS can
provide authentication, integrity, and confidentiality on an
object-by-object basis.
This model can be extended to multiple brokers.
Redirect Broker:
+--------------+ +--------------+ +--------------+
| | | | | |
| Local AAA | | Redirect | | Home AAA |
| Server | | Broker | | Server |
| | | | | |
| +------+ | COPS | +------+ | | |
| |Client|<--|------|-->|Server| | | |
| +------+ | | +------+ | | |
| ^ | | | | |
| | | | | | |
| | | +--------------+ | |
| | | COPS | +------+ |
| +-------|---------------------------|-->|Server| |
| | | +------+ |
+--------------+ +--------------+
Figure 2: A COPS Redirect illustration.
A COPS Redirect broker performs redirect functions so that the
AAA servers can communicate directly. As shown in Figure 2, when
the Redirect broker receives a COPS Request from the Local AAA
Server it sends back a Decision message with the "Redirect
Request" command code (see section 3). The redirection
information is part of the Data Model and is carried in the
Decision message. The Local Server can then directly communicate
with the Home Server.
The Redirect Broker also reduces the configuration information
to be maintained on all the AAA servers.
As with the proxy mode, information from the client that is
intended for the home server only or information from the home
Durham et al. Expires December 2000 [Page 8]
Internet Draft COPS Usage for AAA June 2000
domain intended for the client can be protected using CMS, or
the COPS connection itself can be protected using TLS.
3. COPS Specific Object Formats
In this section, we define new C-Types and other enhancements for
some COPS protocol objects that will be useful for the AAA
framework.
3.1 Context Object (Context)
A new R-Type is added to the context object for identifying an
authentication request form a client to its server.
C-num = 2, C-Type = 1
0 1 2 3
+--------------+--------------+--------------+--------------+
| R-Type | M-Type |
+--------------+--------------+--------------+--------------+
R-Type (Request Type Flag)
0x01 = Incoming-Message/Admission Control request
0x02 = Resource-Allocation request (Authorization)
0x04 = Outgoing-Message request
0x08 = Configuration request
0x10 = Authentication request
3.2 Decision Object (Decision)
Decision made by the PDP. Appears in replies from the server. The
specific non-mandatory decision objects required in a decision to a
particular request depend on the type of client.
C-Num = 6
C-Type = 1, Decision Flags (Mandatory)
0 1 2 3
+--------------+--------------+--------------+--------------+
| Command-Code | Flags |
+--------------+--------------+--------------+--------------+
Commands:
0 = NULL Decision (No configuration data available)
1 = Install (Admit request/Install configuration)
2 = Remove (Remove request/Remove configuration)
3 = Trigger Request
4 = Redirect Request
5 = Trigger Accounting Report
Durham et al. Expires December 2000 [Page 9]
Internet Draft COPS Usage for AAA June 2000
The Trigger Request command code is used when a COPS server wants
the client to resend a Request message. This is used to for both re-
authentication and re-authorization on demand within the AAA model.
The Redirect Request command code is used by a COPS server acting as
a Redirect Broker to indicate that the client must redirect its
Request message to another COPS server.
The Trigger Report is used by the server to force an accounting
report to be issued by the client for the session.
C-Type = 6, CMS Named Decision Data
Named configuration information is encapsulated in this version
of the decision object in response to CMS secured requests. It
is a variable length object and its internal format is specified
in the CMS over COPS extension document [COPSCMS] and by
[COPSPR]. It is optional in Decision messages and is interpreted
relative to both the given context and decision flags.
3.3 Error Object (Error)
This object is used to identify a particular COPS protocol error.
C-Num = 8, C-Type = 1
0 1 2 3
+--------------+--------------+--------------+--------------+
| Error-Code | Error Sub-code |
+--------------+--------------+--------------+--------------+
Additional Error-Code:
16= CMS Authentication Failure [COPSCMS]
3.4 Client Specific Information Object (ClientSI)
The various types of this object are required for requests, and used
in reports and opens when required. It contains client-type specific
information.
C-Num = 9,
C-Type = 1-2, Defined by COPS
C-Type = 3, CMS Named ClientSI.
Variable-length field. Contains named configuration information
protected by CMS [COPSCMS] and its format is defined by [COPSPR].
This encapsulating object is used for relaying structured
Durham et al. Expires December 2000 [Page 10]
Internet Draft COPS Usage for AAA June 2000
information about the PEP, a request, or configured state securely,
end-to-end.
3.5 Report-Type Object (Report-Type)
The Type of Report on the request state associated with a handle:
C-Num = 12, C-Type = 1
0 1 2 3
+--------------+--------------+--------------+--------------+
| Report-Type | ///////////// |
+--------------+--------------+--------------+--------------+
Additional Report-Type:
4 = Acknowledged Accounting:
Accounting update for an installed state that is
to be explicitly acknowledged by the server by
issuing a Decision that specifies the received
accounting information is to be removed by the
client.
3.6 PDP Redirect Address (PDPRedirAddr)
A PDP when closing a PEP session for a particular client-type may
optionally use this object to redirect the PEP to the specified PDP
server address and TCP port number:
C-Num = 13,
C-Type = 1-2, Defined in [COPS]
C-Type = 3, DNS Address + TCP Port
0 1 2 3
+--------------+--------------+--------------+--------------+
| ///////////////////////// | TCP Port Number |
+-----------------------------+-----------------------------+
| NULL Terminated DNS Name ... |
+--------------+--------------+--------------+--------------+
3.7 Last PDP Address (LastPDPAddr)
When a PEP sends a Client-Open message for a particular client-type
the PEP SHOULD specify the last PDP it has successfully opened
(meaning it received a Client-Accept) since the PEP last rebooted.
If no PDP was used since the last reboot, the PEP will simply not
include this object in the Client-Open message.
C-Num = 14,
Durham et al. Expires December 2000 [Page 11]
Internet Draft COPS Usage for AAA June 2000
C-Type = 1-2, Defined in [COPS]
C-Type = 3, DNS Address + TCP Port (Same as Redirect Address)
0 1 2 3
+--------------+--------------+--------------+--------------+
| ///////////////////////// | TCP Port Number |
+-----------------------------+-----------------------------+
| NULL Terminated DNS Name ... |
+--------------+--------------+--------------+--------------+
4. COPS-PR Defined Objects
The COPS Policy Provisioning [COPSPR] clients encapsulate several
objects within the existing COPS Named Client-specific information
object and Named Decision Data object. All the object descriptions
and examples in this document require the Basic Encoding Rules as
the encoding type (S-Type = 1).
The COPS-PR objects are used to communicate data defined within a
Policy Information Base which constitutes the COPS-PR information
model.
CMS over COPS [COPSCMS] defines how these BER-encoded COPS-PR
objects are secured in the CMS Named Client-Specific Information
object and the CMS Named Decision Data object. CMS provides end-to-
end security at the object level for sensitive data.
In the AAA use of COPS-PR, the COPS-PR client-handle is to be
treated as a session identifier. Each client-handle represents a
unique context or non-overlapping and independent namespace
initiated by the client to request authentication of a user and/or
authorization for the use of network resources. Each Decision
corresponds to its respective client-handle and provides a BER
encoded response to the client's request.
5. Common Operation for AAA
COPS for AAA uses COPS-PR defined data in its request for
authentication or authorization of resources. Similarly, Decision
messages use COPS-PR defined data to issue directives to the client
based on its request. Likewise, accounting information is to use the
COPS-PR defined data and is communicated using Report messages to
describe session activity.
1. The Client will open a COPS connection to its server using either
the default COPS security mechanisms or COPS over TLS [COPSTLS].
2. The Client will then send a Client-Open message for the AAA
Client-Type.
Durham et al. Expires December 2000 [Page 12]
Internet Draft COPS Usage for AAA June 2000
3. At any time, the Client can issue a Request identified by its
client-handle carrying COPS-PR defined data relating to user
authentication and/or authorization.
4. The Server analyzes the client's request and determines if the
request can be handled locally or not.
a. If the request can be handled locally, the server responds
with a COPS decision accepting/rejecting the request or
carrying other COPS-PR defined directives for the client.
b. If the request cannot be handled locally, the server will
either redirect the client for the given client-handle to the
appropriate server via a redirect decision or will proxy the
request to the home domain on behalf of the client.
5. The client will abide by the server's decision:
a. If the decision is negative, the client must delete the
request-state or attempt its request again.
b. If the decision was positive, the client must abide by the
directives and limitations specified by the server.
6. Once a request-state has been accepted by the server, the client
MAY send periodic accounting reports specifying the current state
of this AAA session according to the server's directive.
7. At any time, the client can re-authenticate or reauthorize its
request state by simply sending an updated request message for
the same client-handle.
8. At any time, the server may change its decision for the request
state by simply sending an updated decision message.
9. At any time, the server may direct the client to re-authenticate
its session.
10.At any time, the server may direct the client to send an
accounting report for its session.
11.At any time, the client can delete its request state.
12.The client can close its COPS connection by sending a Client-
Close message and closing the underlying TCP connection.
6. Security Considerations
6.1 Hop-by-Hop Security :
The COPS protocol provides an Integrity object that can achieve
authentication, message integrity, and replay prevention. All COPS
implementations MUST support the COPS Integrity object and its
mechanisms as described [COPS]. To ensure the client (PEP) is
communicating with the correct policy server (PDP) requires
authentication of the PEP and PDP using a shared secret, and
consistent proof that the connection remains valid. The shared
secret minimally requires manual configuration of keys (identified
by a Key ID) shared between the PEP and its PDP. The key is used in
conjunction with the contents of a COPS message to calculate a
message digest that is part of the Integrity object. The Integrity
object is then used to validate all COPS messages sent over the TCP
connection between a PEP and PDP.
The COPS Integrity object also provides sequence numbers to avoid
replay attacks. The PDP chooses the initial sequence number for the
Durham et al. Expires December 2000 [Page 13]
Internet Draft COPS Usage for AAA June 2000
PEP and the PEP chooses the initial sequence number for the PDP.
These initial numbers are then incremented with each successive
message sent over the connection in the corresponding direction. The
initial sequence numbers SHOULD be chosen such that they are
monotonically increasing and never repeat for a particular key.
Additionally, in support of AAA, Transport Layer Security [COPSTLS]
SHOULD be used for both connection-level validation and privacy. All
AAA implementations using COPS MUST be capable of supporting TLS.
6.2 End-to-End Security:
COPS for AAA requires the use of CMS for object-level end-to-end
security of named data [COPSCMS]. CMS can be used to sign and/or
encrypt the appropriate PIB data such that it cannot be altered,
undetected, by AAA proxies or other man-in-the-middle components.
What data is to be protected, for which recipients, and how is
defined within the information model or PIB for AAA.
7. IANA Considerations
Durham et al. Expires December 2000 [Page 14]
Internet Draft COPS Usage for AAA June 2000
8. References
[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R.,
Sastry, A., "The COPS (Common Open Policy Service)
Protocol", RFC 2748, August 1999.
[COPSPR] Reichmeyer, F., Herzog, S., Chan, K.H., Seligson, J.,
Durham, D., Yavatkar, R., Gai, S., McCloghrie, K., Smith,
A., "COPS Usage for Policy Provisioning", IETF , October
1999.
[COPSCMS] Walker J., "CMS Over COPS", IETF , June 2000.
[COPSTLS] Walker J., "COPS Over TLS", IETF , June 2000.
[RSVP] Braden, R. ed. et al., "Resource ReSerVation Protocol (RSVP)
Version 1 - Functional Specification", RFC 2205, September
1997.
[WRK] Yavatkar, R. et al., "A Framework for Policy-Based Admission
Control", Internet-Draft, draft-ietf-rap-framework-01.txt,
November 1998.
[SRVLOC] Guttman, E. et al., "Service Location Protocol , Version
2", RFC 2608, June 1999.
[IPSEC] Atkinson, R., "Security Architecture for the Internet
Protocol", RFC 2401, August 1995.
[HMAC] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[TLS] Dierks T., Allen C., "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[IANA] http://www.isi.edu/in-notes/iana/assignments/port-numbers
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
9. Author Information and Acknowledgments
Special thanks to Keith McCloghrie for his valuable contributions.
Avri Doria
Nokia
Durham et al. Expires December 2000 [Page 15]
Internet Draft COPS Usage for AAA June 2000
5 Wayside Road
Burlington MA 01803
+1 781 993 4645
avri.doria@nokia.com
David Durham
Intel
2111 N.E. 25th Avenue JF3-206
Hillsboro OR 97124-5961
1 503 264 6232
david.durham@intel.com
Hormuzd M Khosravi
Intel
2111 N.E. 25th Avenue JF3-206
Hillsboro OR 97124-5961
1 503 264 0334
hormuzd.m.khosravi@intel.com
Walter Weiss
Lucent Technologies
300 Baker Ave.
Concord, MA. 01742
(978) 287-9130
wweiss@lucentctc.com
Durham et al. Expires December 2000 [Page 16]