System for using an authorization token to separate authentication and authorization services

Abstract

A novel system for utilizing an authorization token to separate authentication and authorization services. The system authenticates a client to an authenticating server; generates an authorization token with the authenticating server and the client; and authorizes services for the client using the generated authorization token. The authorization token may be transferred via a third party, or may be utilized to extend an initial session without re-authentication.

Description

CROSS REFERENCE TO RELATED APPLICATION[0001]This application claims the priority benefit of U.S. Provisional Application No. 60 / 867,377, filed Nov. 27, 2006.TECHNICAL FIELD OF THE INVENTION[0002]The present invention relates generally to telecommunications, and more particularly, to a versatile system for using an authorization token to separate authentication and authorization services.BACKGROUND OF THE INVENTION[0003]Conventionally, an act of authentication is not separated from an act of authorization. Typically, once an end-user client is authenticated by an authentication server, that user is also authorized by the same server to use a specific service. In the case that authentication and authorization are performed by the same server, the server is capable of performing cryptographic functions related to authentication. It also has access to user credentials and identities; and may be capable of accessing a user's profile and service access rights, as well as interacting with ...

AI Technical Summary

Benefits of technology

[0021]The present invention provides a system, comprising various methods and apparatus, for using an authorization token to separate authentication and authorization services, and do so in a secure and reliable manner. The system authenticates a client to an authenticating server; generates an authorization token with the authenticating server and the client; and authorizes services for the client using the generated authorization token. The system thus performs the authentication and authorization services separately, and provides satisfactory service security and performances.

[0022]Embodiments of the present invention provide an MN capability to assure an AAAz of a previous authentication with an AAAn. The AAAz is able to verify this authentication with the AAAn, and obtain security material (e.g., SRK) required for operation of system signaling. By providing explicit assurance from the MN within a service request to the AAAz, chances of spoofing and theft of service are significantly reduced. Architecture having separate AAAn and AAAz is thus provided.

Problems solved by technology

As diverse broadband access technologies are increasingly developed and deployed, revenue margins for access providers tend to decrease.

However, this may not be so in the future, if cleaner separation of authentication and authorization functions and servers are developed, and better protection of sensitive authentication credentials against brute force attacks are desired.

This approach is obviously subject to a number of security concerns, however.

For instance, an AAAn server that only performs authentication is not only unaware of future service requests by a peer, but also is not able to provide any such authorization.

Even if an identical peer identifier is used for both authentication and authorization requests with AAAn and AAAz, respectively, there is still no explicit proof presented to the AAAz that the peer has proved this identity to the AAAn.

Furthermore, the lack of a prior state—especially the lack of established security association between the peer (e.g., an MN in MIP protocol) and the AAAz—has a cascading effect on security problems.

Existence of an MN-HA IPsec association can protect service requests on the MN-HA path to the AAAz, but does not provide any integrity or non-repudiation protection for MN service requests outside the MN-HA.

The MSK may be used by several EAP lower layers—however, the EMSK typically remains at a peer and server, and does not appear to be utilized in current specifications or standards.

There are a number of issues that may arise in relation to EAP keying.

There are, however, scenarios where necessary connectivity is not available to support “make before break” communications.

In these scenarios, significant handover latency can result.

To avoid such latency, conventional SDOs have employed methods—such as context transfer and anchoring—that tend to be inefficient, insecure or both.

Other issues may arise where EAP peers—with unexpired keying material from a full EAP exchange—must take part in a full EAP exchange with the same AAA server to extend a session.

Any authentication must pass through this home server, which increases latency.

Images