One document matched: draft-ietf-aaa-solutions-00.txt
INTERNET DRAFT Pat R. Calhoun (editor)
Category: Informational Sun Microsystems, Inc.
Title: draft-ietf-aaa-solutions-00.txt
Date: November 2000
AAA Solutions
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.
This document is an individual contribution for consideration by the
AAA Working Group of the Internet Engineering Task Force. Comments
should be submitted to the diameter@diameter.org and aaa-wg@merit.edu
mailing lists.
Distribution of this memo is unlimited.
Copyright (C) The Internet Society 2000. All Rights Reserved.
Abstract
The AAA Design Team has issued a document that lists issues with the
DIAMETER protocol. This accompanying document is intended as an archive
of proposed solutions. Once accepted, these solutions will find their
way into the relevant DIAMETER specifications.
Calhoun et al. expires May 2001 [Page 1]
INTERNET DRAFT November 2000
Table of Contents
1.0 Introduction
1.1 Requirements language
2.0 Error Codes and Messages
2.1 Result-Code AVP
2.2 Error-Message AVP
3.0 Accounting
4.0 IPv6 Support
5.0 Transports
6.0 Proxies
6.1 Realm-Based Message Routing
6.2 Behavior of Proxy and Redirect Servers
6.2.1 Proxy and Redirect Server handling of requests
6.3 Redirect Server
6.3.1 Redirect-Host AVP
6.3.2 Redirect-Host-Port AVP
6.4 Proxy Server
6.4.1 Proxying Requests
6.4.2 Proxying Responses
6.4.2.1 Route-Record AVP
6.4.2.2 Proxy-State AVP
6.4.2.3 Home-Realm AVP
6.5 Applying Local Policies
6.6 Hiding Network Topology
7.0 RADIUS Compatibility
8.0 End-to-End Security
9.0 Data Model
10.0 SNMP Support (DIAMETER MIB)
11.0 Re-Authentication & Authorization
12.0 Server/Resource Management State
13.0 Access Rules and Filters
14.0 AAA Server Discovery
15.0 Loop Detection
16.0 IANA Considerations
17.0 Security Considerations
18.0 Acknowledgments
19.0 References
20.0 Authors' Addresses
21.0 Full Copyright Statement
Calhoun et al. expires May 2001 [Page 2]
INTERNET DRAFT November 2000
1.0 Introduction
The AAA Design Team has issued a document that lists issues with the
DIAMETER protocol [11]. This accompanying document is intended as an
archive of proposed solutions. Once accepted, these solutions will
find their way into the relevant DIAMETER specifications.
Each main section should specify which DIAMETER documents its sub-
sections are targetted at. Ideally, the section should also state
whether the proposed text is intended to replace existing text, or
added as new text.
2.0 Error Codes and Messages
Section 2.1 below is intended to replace the current section 5.2 in
the Base Protocol [1] specification. Section 2.2 is intended as a new
section 5.3 in the Base Protocol [1].
The existing Base Protocol defines the Result-Code AVP to be of type
Complex, while the following section defines the Result-Code AVP to
be of type Integer, and a separate Error-Message AVP of type String.
2.1 Result-Code AVP
The Result-Code AVP (AVP Code 268) is of type Integer and indicates
whether a particular request was completed successfully or whether an
error occurred. All DIAMETER messages of type *-Response or *-Answer
MUST include one Result-Code AVP.
The Result Code field contains an IANA-managed 32-bit address space
representing errors (see section 8.4). The DIAMETER provides five
different classes of errors, all identified by the thousands digit:
- 1xxx (Informational)
- 2xxx (Success)
- 3xxx (Redirect Notification)
- 4xxx (Transient Failures)
- 5xxx (Permanent Failure)
2.1.1 Informational
Errors that fall within the Informational category are used to inform
a requestor that the request cannot be immediately satisfied and a
further response will be issued in the near future.
DIAMETER_BE_PATIENT 1001
Calhoun et al. expires May 2001 [Page 3]
INTERNET DRAFT November 2000
The DIAMETER server responsible for authentication and/or
authorizing the user cannot satisfy the request at the moment,
and will respond within the next 3 seconds.
2.1.2 Success
Errors that fall within the Success category are used to inform a
peer that a request has been successfully completed.
DIAMETER_SUCCESS 2000
The Request was successfully completed.
2.1.3 Redirect Notification
Errors that fall within the Redirect Notification category are used
to inform a peer that the request cannot be satisfied locally and
should instead be forwarded to another server.
DIAMETER_REDIRECT_INDICATION 3001
A proxy or redirect server has determined that the request
could not be satisfied locally and the initiator of the request
should direct the request directly to the server, whose contact
information has been added to the response. This error code
MUST NOT be sent in a Message-Reject-Ind message.
2.1.4 Transient Failures
Errors that fall within the transient failures category are used to
inform a peer that the request could not be satified at the time it
was received, but MAY be able to satisfy the request in the future.
DIAMETER_TIME_INVALID 4001
This Result-Code value is return to inform a peer that the
message received contained an invalid timestamp value (in
Timestamp AVP).
DIAMETER_AUTHENTICATION_REJECTED 4002
The authentication process for the user failed, most likely due
to an invalid password used by the user. Further attempts MUST
only be tried after prompting the user for a new password.
DIAMETER_AUTHORIZATION_FAILED 4003
A request was received for which the user could not be
authorized at this time. This error could occur when the user
has already expended allowed resources, or is only permitted to
Calhoun et al. expires May 2001 [Page 4]
INTERNET DRAFT November 2000
access services within a time period.
DIAMETER_UNABLE_TO_DELIVER 4004
The request could not be delivered to a host that handles the
realm requested at this time.
DIAMETER_NO_END_2_END_SECURITY 4005
A proxy has detected that end-to-end security has been applied
to portions of the DIAMETER message, and the proxy does not
allow this security mode since it needs to alter the message by
applying some local policies.
DIAMETER_CONTRADICTING_AVPS 4006
The Home DIAMETER server has detected AVPs in the request that
contradicted each other, and is not willing to provide service
to the user. One or more Failed-AVP MUST be present, containing
the AVPs that contradicted each other.
2.1.5 Permanent Failures
Errors that fall within the permanent failures category are used to
inform the peer that the request failed, and should not be attempted
again.
DIAMETER_USER_UNKNOWN 5001
A request was received for a user that is unknown, therefore
authentication and/or authorization failed.
DIAMETER_COMMAND_UNSUPPORTED 5002
The Request contained a Command-Code that the receiver did not
recognize or support. The Message-Reject-Ind message MUST also
contain a Unknown-Command-Code AVP containing the unrecognized
Command-Code.
DIAMETER_AVP_UNSUPPORTED 5003
The peer received a message that contained an AVP that is not
recognized or supported and was marked with the Mandatory bit.
A DIAMETER message with this error MUST contain one or more
Failed-AVP AVP containing the AVPs that caused the failure.
DIAMETER_REALM_NOT_SERVED 5004
A proxy or redirect server has determined that it is unable to
forward the request or provide redirect information since the
realm portion of the NAI requested is unknown.
DIAMETER_UNSUPPORTED_TRANSFORM 5005
A message was received that included an Integrity-Check-Value
Calhoun et al. expires May 2001 [Page 5]
INTERNET DRAFT November 2000
or CMS-Data AVP [11] that made use of an unsupported transform.
DIAMETER_UNKNOWN_SESSION_ID 5006
The request or response contained an unknown Session-Id.
DIAMETER_AUTHORIZATION_REJECTED 5007
A request was received for which the user could not be
authorized. This error could occur if the service requested is
not permitted to the user.
DIAMETER_INVALID_AVP_VALUE 5008
The request contained an AVP with an invalid value in its data
portion. A DIAMETER message with this result code MUST include
the offending AVPs within a Failed-AVP AVP.
DIAMETER_MISSING_AVP 5009
The request did not contain an AVP that is considered mandatory
by the Command Code definition. If this value is sent in the
Result-Code AVP, a Failed-AVP AVP SHOULD be included in the
message. The data portion of the Failed-AVP MUST have its AVP
Code set to the value of the missing AVP.
DIAMETER_INVALID_AUTH 5010
The Request did not contain a valid Integrity-Check-Value or
CMS-Data [11] AVP.
DIAMETER_LOOP_DETECTED 5011
A Proxy or Redirect server detected a loop while trying to get
the message to the Home DIAMETER server. Further attempts
should not be attempted until the loop has been fixed.
2.2 Error-Message AVP
The Error-Message AVP (AVP Code 281) is of type String and MAY be
present if the message also contains a non-successful Result-Code
AVP. The AVP MUST contain a human readable error message. The Error-
Message AVP is not intended to be useful in real-time, and SHOULD NOT
be expected to be parsed by network entities.
3.0 Accounting
4.0 IPv6 Support
Calhoun et al. expires May 2001 [Page 6]
INTERNET DRAFT November 2000
5.0 Transports
6.0 Proxies
This section contains text that is intended to replace all of section
6 in the DIAMETER Base protocol [1]. This section contains
clarifications on the expected behavior of DIAMETER proxies and
redirect servers, and also introduces new AVPs.
6.1 Realm-Based Message Routing
DIAMETER Message routing is done through the use of the realm portion
of the Network Access Identifier (NAI), and an associated realm
routing table (see section 10.0). The NAI has a format of user@realm,
and DIAMETER servers have a list of locally supported realms, and MAY
have a list of externally supported realms. When a message is
received that includes a realm that is not locally supported, the
message is proxied to the DIAMETER entity configured in the "route"
table.
There are instances where the User-Name AVP is not present in
authorization requests. This is typically true in networks where a
request is sent to the network before the call was even answered.
However, such requests MAY need to be proxied. In such cases, the
first hop DIAMETER proxy MUST append the Home-Realm AVP to the
DIAMETER message, by using a DNIS or ANI to Home-Realm association
table.
Figure 1 depicts an example where DIA1 receives a request to
authenticate user "joe@abc.com". DIA1 looks up "abc.com" in its local
realm route table and determines that the message must be proxied to
DIA2. DIA2 does the same check, and proxies the message to DIA3. DIA3
checks its realm route table, and determines that the realm is
locally supported, and processes the authentication request, and
returns the response. How the response actually makes it back to the
sender of the original request is described in the next section.
Calhoun et al. expires May 2001 [Page 7]
INTERNET DRAFT November 2000
(Request) (Request)
(User-Name=joe@abc.com) (User-Name=joe@abc.com)
+------+ ------> +------+ ------> +------+
| | | | | |
| DIA1 +-------------------+ DIA2 +-------------------+ DIA3 |
| | | | | |
+------+ <------ +------+ <------ +------+
(Response) (Response)
(User-Name=joe@abc.com) (User-Name=joe@abc.com)
mno.net xyz.com abc.com
Figure 1: Realm-Based Routing
6.2 Behavior of Proxy and Redirect Servers
This section describes the behavior of DIAMETER proxy and redirect
servers in detail. In both cases, determining the next hop for a
DIAMETER message is done via the Home-Realm or the User-Name AVP [1],
whose syntax must comply with the Network Access Identifier (NAI)
[12] specification. When present, the Home-Realm takes precedence
over the User-Name AVP for routing decisions. The Home-Realm AVP, or
the realm portion of the User-Name AVP is used to identify the next
hop server the message must be forwarded to.
Note the processing rules contained in this section are intended to
be used as general guidelines to DIAMETER developers. Certain
implementations MAY use different methods than the ones described
here, and still be in compliance with the protocol specification.
6.2.1 Proxy and Redirect Server handling of requests
Any request received by a DIAMETER server MUST perform a next hop
lookup. Lookups are performed against what is commonly known as the
Domain Routing Table (see section 10.0). A Domain Routing Table Entry
contains the following fields:
- Domain Name. The Domain Name is analogous to the realm portion
of the NAI. This is the field that is typically used as a
primary key in the routing table lookups. Note that some
implementations perform their lookups based on longest-match-
from-the-right on the realm rather than requiring an exact
match.
- Extension Id. It is possible for a routing entry to have a
different destination based on the extension identifier of the
message. This field is typically used as a secondary key field
in routing table lookups.
- Local Action. The Local Action field is used to identify how a
Calhoun et al. expires May 2001 [Page 8]
INTERNET DRAFT November 2000
message should be treated. The following actions are supported:
1. LOCAL - DIAMETER messages that resolve to a routing entry
with the Local Action set to Local can be satisfied
locally, and do not need to be forwarded to another
server.
2. PROXY - All DIAMETER messages that fall within this
category MUST be forwarded to a next hop server. The local
server MAY apply its local policies to the message by
including new AVPs to the message prior to forwarding.
See section 6.4 for more information.
3. REDIRECT - DIAMETER messages that fall within this
category MUST have the identity of the home DIAMETER
server(s) appended, and returned to the sender of the
message. See section 6.3 for more information.
4. OTHER - If anyone has any ideas, please let me know what
an "other" really is.
- Server Identifier - One or more servers the message is to be
forwarded to. When the Local Action is set to PROXY, this field
contains the identities of the server the message must be
forwarded to. When the Local Action field is set to REDIRECT,
this field contains the Home DIAMETER server(s) for the realm.
It is important to note that DIAMETER servers MUST support at least
one of the PROXY, REDIRECT, or LOCAL modes of operation. Servers do
not need to support all modes of operation in order to conform with
the protocol specification. Server MUST NOT reorder AVPs with the
same AVP Code.
6.3 Redirect Server
A Redirect Server is one that provides NAI Realm to DIAMETER Home
Server address resolution. When a message is received by a peer, the
Home-Realm or the realm portion of the User-Name AVP is extracted
from the message, and the realm portion is used to perform a lookup
in the domain routing table. Implementations SHOULD also use the
Extension Id as a secondary key in the domain routing table lookup.
Successful routing table lookups will return one or more home
DIAMETER server that could satisfy the message. The home servers are
encoded in one or more Redirected-Host, and optional Redirect-Host-
Port AVPs [1]. In the event that more than one such home server is
returned, each AVP pair MUST be encapsulated within a Grouped-AVP.
Calhoun et al. expires May 2001 [Page 9]
INTERNET DRAFT November 2000
+------------------+
| DIAMETER |
| Redirect Server |
+------------------+
^ |
Request | | Response +
joe@xyz.com | | Result Code =
| | Redirect
| v
+----------+ Request +----------+
| abc.net |------------->| xyz.net |
| DIAMETER | | DIAMETER |
| Server |<-------------| Server |
+----------+ Response +----------+
Figure 4: DIAMETER Redirect Server
Lastly, the Result-Code AVP is added with the value of the AVP set to
DIAMETER_REDIRECT_INDICATION [1], and the message is returned to the
sender of the request. Redirect servers MAY also include the
certificate of the Home server(s). These certificates are
encapsulated in a CMS-Data AVP [11]. When this occurs, the server
forwarding the request directly to the Home DIAMETER server SHOULD
include its own certificate in the message.
6.3.1 Redirect-Host AVP
The Redirect-Host AVP (AVP Code 278) is of type Address and is
returned in a response that has the Result-Code AVP set to
DIAMETER_REDIRECT_REQUEST. This AVP includes the IP address of the
DIAMETER host to which the request MUST be redirected. The presence
of multiple Redirect-Host AVPs within the same Grouped-AVP, implies
that all of the addresses MAY be used to contact the same host. When
multiple AVPs are found that are un-grouped, or grouped with
different Grouped-AVPs, they represent separate hosts. Upon receipt
of such a Result-Code, and this AVP, a DIAMETER host SHOULD send the
request directly to one of the hosts.
6.3.2 Redirect-Host-Port AVP
The Redirect-Host-Port AVP (AVP Code 277) is of type Integer32 and
MAY be present when the Redirect-Host AVP is present. The absence of
this AVP implies that the reserved port MUST be used.
6.4 Proxy Server
Calhoun et al. expires May 2001 [Page 10]
INTERNET DRAFT November 2000
This section outlines the processing rules for DIAMETER proxy
servers. A proxy server can either be stateful or stateless. A Proxy
server MAY act in a stateful manner for some requests, and be
stateless for others. There are two types of states that servers MAY
wish to maintain; transaction and session.
Maintaining transaction state implies that a server keeps a copy of a
request, which is then used when the corresponding response is
received. This could be done to apply local policies to the message,
or simply for auditing purposes. Maintaining session state implies
that a server keeps track of all "active" users. An active user is
one that has been authorized for a particular service, and the server
has not received any indication that the user has relinquished
access.
A stateless proxy is one that does not maintain transaction, nor
session state. It frees the messages sent once acknowledgements are
received by the transport layer.
A stateful proxy can be viewed as a DIAMETER Server upon receiving a
request, and as a Client when forwarding the message. For all
intensive purposes, stateful servers terminate an upstream "session",
and initiates a downstream "session" (see figure x), and MAY provide
the following features:
- Protocol translation (e.g. RADIUS <-> DIAMETER)
- Limiting resources authorized to a particular user
- Per user or transaction auditing
+--------+ +-----------------+ +--------+
| Client | --------> | Server | Client | -------> | Server |
+--------+ +-----------------+ +--------+
Figure x - Example of Stateful Proxy
A stateful proxy that maintains transaction state SHOULD release
transaction information after a request's corresponding response has
been forwarded towards the recipient, and has been acknowledged by
the underlying transport.
A stateful proxy that maintains session state SHOULD release the
session state once it is informed that a user and/or device is has
relinquished access.
Home servers processing requests that include the Route-Record and/or
the Proxy-State AVPs MUST return these AVPs in the same order in the
corresponding response.
6.4.1 Proxying Requests
Calhoun et al. expires May 2001 [Page 11]
INTERNET DRAFT November 2000
A proxy server MUST check for forwarding loops before proxying a
request. A request has been looped if the server finds its own
address in a Route-Record AVP (see [1] for more information on loop
detection).
A DIAMETER server that proxies a request MUST append a Route-Record
AVP, which includes its identity. DIAMETER Servers that receive
messages MUST validate the last Route-Record AVP in the message and
ensure that the host identified in the AVP is the same as the sender
of the message.
A Proxy Server MAY also include the Proxy-State AVP, which is used to
encode local state information. The Proxy-State AVP is guaranteed to
be present in the corresponding response. If the Proxy-State AVP is
present, both the Route-Record and the Proxy-State AVPs MUST be
encapsulated within the Grouped-AVP AVP.
The message is then forwarded to the downstream DIAMETER server, as
identified in the Domain Routing Table.
6.4.2 Proxying Responses
A proxy server MUST only process responses whose last Route-Record
AVP matches one of its addresses. Any responses that do not conform
to this rule MUST be dropped. The last Route-Record AVP MUST be
removed from the message before it is forwarded to the next hop,
which is identified by the second to last Route-Record AVP.
6.4.2.1 Route-Record AVP
The Route-Record AVP (AVP Code 282) is of type String, and contains
the Fully Qualified Domain Name of the Proxy appending the AVP to a
DIAMETER message.
6.4.2.2 Proxy-State AVP
The Proxy-State AVP (AVP Code 33) [1] is used by proxy servers when
forwarding requests and contains opaque data that is used by the
proxy to further process the response. Such data may include AVPs
that are to be added to the response, information about the
downstream peer, etc.
6.4.2.3 Home-Realm AVP
Calhoun et al. expires May 2001 [Page 12]
INTERNET DRAFT November 2000
The Home-Realm AVP (AVP Code 283) is of type String and contains the
realm portion of the Network Access Identifier. When present, the
Home-Realm AVP MUST be used to perform any message routing decisions.
6.5 Applying Local Policies
Proxies MAY apply local access policies to DIAMETER requests, or
responses, by adding, changing or deleting AVPs in the messages.
Proxies that apply local policies MUST NOT allow end-to-end security
on any messages that traverse through it, unless security is
terminated locally.
A proxy wishing to modify a DIAMETER message to enforce some local
policy that detects that end-to-end security has been applied to the
message MUST return a reponse to the originator with the Result-Code
set to DIAMETER_NO_END_2_END_SECURITY. The originator of the request
MAY re-issue the request with no end-to-end security if it falls
within its local policy.
In the event that the Home DIAMETER server receives a request with
contradictory information (possibly due to some proxy adding a local
policy), it MAY accept the latest AVP, or MAY return the response
with the Result Code AVP set to DIAMETER_CONTRADICTING_AVPS. However,
a NAS receiving a response that contains contradictory information
SHOULD reject service to the user.
6.6 Hiding Network Topology
Stateful proxies forwarding requests to servers outside of their
administrative domain MAY hide the internal network topology. Servers
perform this by removing all Route-Record AVPs in the message, and
maintains the Route-Record AVPs to add to the corresponding response.
Such stateful servers MUST still add their own Route-Record AVP to
the request prior to forwarding.
7.0 RADIUS Compatibility
8.0 End-to-End Security
9.0 Data Model
Calhoun et al. expires May 2001 [Page 13]
INTERNET DRAFT November 2000
10.0 SNMP Support (DIAMETER MIB)
11.0 Re-Authentication & Authorization
12.0 Server/Resource Management State
13.0 Access Rules and Filters
14.0 AAA Server Discovery
15.0 Loop Detection
This section describes how proxies detect messages that are looping
through the same set of entities. This section is targetted to be
numbered 6.7 in the DIAMETER Base protocol [1].
15.1 Loop Detection
When a DIAMETER Proxy or Redirect server receives a request, it MUST
examine all Route-Record AVPs in the message to determine whether
such an AVP already exists with the local server's identity. If an
AVP with the local host's identity is found in the request, it is an
indication that the message is being looped through the same set of
proxies. When such an event occurs, the DIAMETER server that detects
the loop returns a response with the Result-Code AVP set to
DIAMETER_LOOP_DETECTED.
16.0 IANA Considerations
DIAMETER makes extensive use of IDs (command codes, extensions,
result codes, AVP attributes, Integrity-Check-Value AVP Transform
code). These are collected in the base protocol specification, but
defined in the DIAMETER extension docs.
17.0 Security Considerations
Calhoun et al. expires May 2001 [Page 14]
INTERNET DRAFT November 2000
DIAMETER [1] is a framework providing authentication and
authorization services for network access. Section 11 and 13 concern
how these features could be refined or improved in subsequent work.
DIAMETER itself contains a number of security features. Section 8
discusses how these could be redesigned for less reliance on public
key cryptography.
18.0 Acknowledgments
At this time, the authors have themselves to thank :)
19.0 References
[1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman. "DIAMETER Base
Protocol", draft-calhoun-diameter-17.txt, IETF work in progress,
September 2000.
[2] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "DIAMETER NASREQ
Extension", draft-calhoun-diameter-nasreq-05.txt, IETF work in
progress, September 2000.
[3] Calhoun, Zorn, Pan, Akhtar, "DIAMETER Framework", draft-
calhoun-diameter-framework-08.txt, IETF work in progress, June
2000.
[4] P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extensions", draft-
calhoun-diameter-mobileip-11.txt, IETF work in progress, Sep-
tember 2000.
[5] P. Calhoun, W. Bulley, S. Farrell, "DIAMETER Strong Security
Extension", draft-calhoun-diameter-strong-crypto-05.txt (work in
progress), September 2000.
[6] Arkko, Calhoun, Patel, Zorn, "DIAMETER Accounting Extension",
draft-calhoun-diameter-accounting-08.txt, IETF work in progress,
September 2000.
[7] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, W. Bulley, J.
Haag, "DIAMETER Implementation Guidelines", draft-calhoun-
diameter-impl-guide-03.txt, IETF work in progress, June 2000.
[8] P. Calhoun, N. Greene, "DIAMETER Resource Management", draft-
calhoun-diameter-res-mgmt-05.txt, IETF Work in Progress, Sep-
tember 2000.
Calhoun et al. expires May 2001 [Page 15]
INTERNET DRAFT November 2000
[9] Aboba et al, "Network Access AAA Evaluation Criteria", IETF work
in progress, draft-ietf-aaa-na-reqts-07.txt, August 2000.
[10] Mitton et al, "Authentication, Authorization, and Accounting:
Protocol Evaluation", IETF work in progress, draft-ietf-aaa-
proto-eval-00.txt, July 2000.
[11] Calhoun et al., "AAA Problem Statements", IETF work in progress,
draft-ietf-aaa-issues-01.txt, October 2000.
[12] Aboba, Beadles "The Network Access Identifier." RFC 2486. Janu-
ary 1999.
20.0 Authors' Addresses
Questions about this memo can be directed to:
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
E-mail: pcalhoun@eng.sun.com
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Phone: +1 425 936-6605
Fax: +1 425 936-7329
E-mail: bernarda@microsoft.com
Erik Guttman
Network and Security Research Center, Sun Laboratories
Sun Microsystems, Inc.
Eichhoelzelstr. 7
74915 Waibstadt
Germany
Calhoun et al. expires May 2001 [Page 16]
INTERNET DRAFT November 2000
Phone: +49-7263-911-701
E-mail: erik.guttman@germany.sun.com
David Mitton
Nortel Networks
880 Technology Park Drive
Billerica, MA 01821
USA
Phone: +1 978 288 4570
E-mail: dmitton@nortelnetworks.com
David B. Nelson
Enterasys Networks, Inc. (a Cabletron Systems company)
50 Minuteman Road
Andover, MA 01810-1008
USA
Phone: +1 978 684 1330
E-Mail: dnelson@enterasys.com
Juergen Schoenwaelder
Technical University Braunschweig
Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig,
Germany
Phone: +49 531 391 3289
Fax: +49 531 391 5936
E-Mail: schoenw@ibr.cs.tu-bs.de
Barney Wolff, Pres.
Databus Inc.
15 Victor Drive
Irvington, NY 10533-1919 USA
USA
Phone: +1 914 591 5677
E-mail: barney@databus.com
Lixia Zhang
UCLA Computer Science Department
4531G Boelter Hall
Calhoun et al. expires May 2001 [Page 17]
INTERNET DRAFT November 2000
Los Angeles, CA 90095-1596
USA
Phone: +1 310 825 2695
E-Mail: lixia@cs.ucla.edu
21.0 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 docu-
ment 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 develop-
ing 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 lim-
ited 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 DIS-
CLAIMS 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.
Calhoun et al. expires May 2001 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-21 18:37:31 |