One document matched: draft-ietf-aaa-roamops-auth-req-00.txt
INTERNET DRAFT Pat R. Calhoun
Category: Standards Track Sun Microsystems, Inc.
Title: draft-ietf-aaa-roamops-auth-req-00.txt Glen Zorn
Date: March 1999 Microsoft Corporation
Roamops Authentication/Authorization Requirements
Status of this Memo
This document is a submission by the AAA Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the aaa-wg@merit.edu mailing list.
Distribution of this memo is unlimited.
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.
Abstract
The AAA Working Group is currently looking at defining the
requirements for Authentication and Authorization. This document
contains the requirements for Roaming Operations.
1.0 Introduction
Calhoun, Zorn expires August 1999 [Page 1]
INTERNET DRAFT March 1999
In non-roamops environments, a typical AAA deployment would consist
of a Policy Enforcement Point (PEP), and a Policy Decision Point
(PDP). The PEP receives a request for service from a user or device,
and in turn issues an Authentication/Authorization request to the
PDP.
+------+ +-----+ +-----+
| user | | PEP | | PDP |
+------+ +-----+ +-----+
-------->
Request for service
--------------------->
Authentication/Authorization (AA)
<---------------------
Reply w/ authorization info
<--------
Service is offered
The PDP authenticates the user, makes some authorization decisions
based on the user or device's profile, and issues a reply. The reply
MAY include additional authorization information, which the PEP uses
to perform additional authorization decisions before offering the
service to the user/device.
Much of the work in progress within ROAMOPS allows the AAA server to
take a much more active role in the authentication phase. This is
intended to increase the security, especially in roaming
environments, where replay of previous authentication sessions is
very easy. The unfortunate side-effect of this feature is that it
requires more exchanges between the PEP and the PDP, as shown below.
Calhoun, Zorn expires August 1999 [Page 2]
INTERNET DRAFT March 1999
+------+ +-----+ +-----+
| user | | PEP | | PDP |
+------+ +-----+ +-----+
-------->
Request for service
--------------------->
AA Req w/ identity
<---------------------
AA Reply w/ Challenge
<--------
Challenge
-------->
Response
--------------------->
AA Req w/ Response
<---------------------
Reply w/ authorization info
<--------
Service is offered
In the above example, when the PEP issues the initial AA request to
the PDP, it includes the user's identity (ideally in the format
defined by the Network Access Identifier (NAI) specification [1]).
The PDP issues some challenge to the PEP, which is then forwarded to
the user/device. This challenge could in fact be encapsulated within
an EAP [2] or SASL [3] envelope, which would allow for user/device to
PDP authentication using existing authentication frameworks. Once the
PDP determines that the user/device has satisfactorily authenticated
itself, access is granted which includes authorization information.
There have been some discussions in the AAA working group to
logically split the authentication and authorization phase, possibly
into two different protocols. The resulting protocol would look like
the following figure:
Calhoun, Zorn expires August 1999 [Page 3]
INTERNET DRAFT March 1999
+------+ +-----+ +-----+
| user | | PEP | | PDP |
+------+ +-----+ +-----+
-------->
Request for service
--------------------->
Authen. Req w/ identity
<---------------------
Authen. Reply w/ Challenge
<--------
Challenge
-------->
Response
--------------------->
Authen. Req w/ Response
<---------------------
Authen. Reply w/ token
--------------------->
Authorization Req w/ token
<---------------------
Reply w/ authorization info
<--------
Service is offered
In this instance, the PEP initially sends the authentication request
to the PDP. Upon successful authentication, the PDP returns some form
of signed token back in the reply. The PEP would then issue the
authorization request to the PDP, which would look at the token (to
ensure that authentication had already occured), authorize the
user/device, and return a reply that contains the additional
authorization information.
Since it is very possible for the authentication and authorization to
be performed by two different PDPs, each specializing in their own
area, the above example does allow for such a logical split in
functionality. The Authentication PDP could support a specific
manufacturer's token card, or biometric authentication.
In the roamops model, it is assumed that the user/device cannot be
authenticated and authorized locally. This means that the user/device
requests service from a provider that is not its "home" provider.
Therefore, the visited domain must forward the request to the user's
home domain in order to perform the Authentication and Authorization.
A reply from the home domain may be construed as "willingness to pay"
for the service provided to the requesting user/device.
Calhoun, Zorn expires August 1999 [Page 4]
INTERNET DRAFT March 1999
Visited Home
+------+ +-----+ +-----+ +-----+
| user | | PEP | | PDP | | PDP |
+------+ +-----+ +-----+ +-----+
-------->
Request for service
--------------------->
Authen. Req Req (includes identity)
------------->
Authen. Req w/ identity
<-------------
Authen. Rep. w/ Challenge
<---------------------
Authen. Reply w/ Challenge
<--------
Challenge
-------->
Response
--------------------->
Authen. Req w/ Response
------------->
Authen. Req w/ Response
<-------------
Authen. Reply w/ token
<---------------------
Authen. Reply w/ token
--------------------->
Autho. Req w/ token
------------->
Autho. Req w/ token
<-------------
Reply w/ authorization
info
<---------------------
Reply w/ authorization info
<--------
Service is offered
In the above diagram, the Visited PDP forwards the request to the
home PDP. The Home PDP is known using the identity, which is some
cases is the NAI. It is equally possible for the visited PDP to
simply forward the request to a broker, which it shares a trust
relationship with, which in turn forwards the request to the home
PDP.
Calhoun, Zorn expires August 1999 [Page 5]
INTERNET DRAFT March 1999
Visited Broker Home
+------+ +-----+ +-----+ +-----+ +-----+
| user | | PEP | | PDP | | PDP | | PDP |
+------+ +-----+ +-----+ +-----+ +-----+
Here each message will traverse the internet, possibly twice for each
message if a broker is involved. Many of the services which will be
using AAA stated that one of their requirement was to be able to use
AAA and not impose an additional long latency. Therefore, it is
paramount that we attempt to limit the number of messages required
for the authentication and authorization phase. Ideally, the
authentication request *should* include a request for authorization.
This also has the advantange of reducing the Inter-Domain trust
relationships to one (instead of one for authentication and one for
authorization).
When brokers are involved, it is necessary that a end-to-end (Visited
to Home PDP) trust relationship be established in order to prevent
from fraudulent broker activity. Otherwise, it would be possible for
the broker to modify authorization information that was returned by
the home domain's PDP. It should therefore be possible for the broker
to return a forwarding address to the visited network's PDP, and
allow the local PDP to contact the "home" PDP directly, using the
end-to-end trust relationship for authentication and authorization.
However, accounting messages MUST flow through the broker. This
decision is up to the broker's policy on whether a forwarding address
is returned, or the request is proxied to the home domain.
Note that the PDP can still interface with a specialized
authentication server for support of token cards or biometrics, as
shown below. In this case, the interface between the PDP and the
specialized Authentication server MAY use the AAA protocol, or may
use a proprietary protocol. However, this is clearly outside this
scope of this document. If the Authentication server is required,
this should exist within the home domain, and should not be exposed
to the visited domain, especially if the interface to the
authentiation server is proprietary.
+------+ +-----+ +-----+ +------+
| user | | PEP | | PDP | | Auth |
+------+ +-----+ +-----+ +------+
3.0 Conclusion
The ROAMOPS working group has the following requirements:
- Allow existing Authentication Frameworks (EAP, SASL) to be
Calhoun, Zorn expires August 1999 [Page 6]
INTERNET DRAFT March 1999
transported over the AAA protocol for user/device
authentication.
- Allow for separate authorization when necessary, but the
AAA protocol MUST allow for a single message to request both
authentication and authorization.
- The AAA protocol MUST be "proxyable", meaning that a PDP
MUST be able to forward the request to another PDP, which
may or may not be within the same administrative domain.
- The AAA protocol MUST allow for intermediate brokers to
add their own local Authorization information to a request
or response.
- When a broker is involved, the protocol MUST provide end to
end security.
- The broker MUST be able to return a forwarding address to
a requestor, allowing two nodes to communicate together.
Furthermore, the protocol MUST provide the following features (per
user session):
- One Authentication, One Authorization
- One Authentication, Multiple Authorization
- Multiple Authentication, Multiple Authorization
4.0 References
[1] L. Blunk, J. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998.
[2] B. Aboba, M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.
[3] J. Myers, "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
Calhoun, Zorn expires August 1999 [Page 7]
INTERNET DRAFT March 1999
5.0 Author's Address
Questions about this memo can be directed to:
Pat R. Calhoun
Network and Security Research Center
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: 1-650-786-7733
Fax: 1-650-786-6445
E-mail: pat.calhoun@eng.sun.com
Glen Zorn
Microsoft Corporation
One Microsoft Way
Redmond, Washington 98052
Phone: +1 425 703 1559
E-Mail: glennz@microsoft.com
Calhoun, Zorn expires August 1999 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-21 18:26:27 |