US20080178274A1 - System for using an authorization token to separate authentication and authorization services - Google Patents
System for using an authorization token to separate authentication and authorization services Download PDFInfo
- Publication number
- US20080178274A1 US20080178274A1 US11/938,048 US93804807A US2008178274A1 US 20080178274 A1 US20080178274 A1 US 20080178274A1 US 93804807 A US93804807 A US 93804807A US 2008178274 A1 US2008178274 A1 US 2008178274A1
- Authority
- US
- United States
- Prior art keywords
- service
- server
- client
- authorization
- authentication
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
- H04L9/3242—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0892—Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
Definitions
- 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.
- an act of authentication is not separated from an act of authorization.
- an end-user client is authenticated by an authentication server, that user is also authorized by the same server to use a specific service.
- 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 service equipment to see if service may be granted.
- MIPv6 Mobile Internet Protocol v6
- AAA Authenticating, Authentication, and Authorization
- Service provider equipment and infrastructure may be different from network access equipment.
- a MIP Home Agent HA
- a network access server/Extensible Authentication Protocol (EAP) authenticator may be part of a network access provider.
- EAP Extensible Authentication Protocol
- Kerberos is a conventional technology for performing authentication and authorization separately.
- a token is generated in an authentication process, and is used for authorization.
- KDC Key Distribution Center
- a token is service specific, and is encrypted with a key, known only to the service server. Retrieval of the token requires additional roundtrips between a client and the KDC server.
- EAP extensible authentication protocol
- MIPv6 operation requires bootstrapping of various parameters—such as home address, home agent address, and IPsec security associations—efforts in the IETF are underway to perform such bootstrapping through AAA infrastructure.
- IKEv2 authentication To get around the need for pre-shared key for IKEv2 authentication, the MN authenticates through a MIP home agent (HA) to a backend AAAn, using EAP.
- EAP authentication is done as part of an IKEv2 exchange.
- the authentication of an MN is only part of the MIP service establishment procedure. Once the MN completes the IKEv2-EAP authentication, and establishes an IPsec channel with the HA, it still needs to be authorized for use MIP service. This typically means that an authorization server (usually also an AAA server) needs to perform the act of authorization.
- AAA-EAP an authenticating AAA server
- MIPAAA an authorizing server
- 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.
- an AAAn as an entity performing EAP, is the only entity allowed to cache EMSK—since EMSK is not allowed to be transported outside AAAn [EAPKEYING].
- MIPv6_USRK Mobile IPv6 usage specific root key
- MIP service is authorized only at AAAz. This means that the MIPv6-USRK must be created only after such authorization, and be accessible to the AAAz for generation of other MIPv6 security keys.
- MIPv6_USRK requires access to other “usage data” specific for Mobile IPv6; which is typically not available at the AAAn.
- the AAAz must make the “usage data” available to the AAAn, and request MIPv6_USRK from the AAAn, in order to be able to generate further MIPv6 keys.
- HOKEY Handover Keying
- deployments of EAP in wireless networks employ an authenticator in pass-through mode (typically located at an edge) coupled with a backend AAA/EAP server.
- a number of conventional EAP systems generate an MSK and an EMSK.
- 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. Different EAP lower layers make use of the MSK differently.
- TSKs Transient Session Keys
- 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.
- EAP systems do provide re-authentication mechanisms, more consistent, low-latency, EAP-method-independent, re-authentication mechanisms are needed.
- an EAP-generated EMSK key may be used as a root of a cryptographic key hierarchy—where keys in the hierarchy are then used in various ways to provide necessary security services.
- cross-domain roaming is typically handled by inter-domain authentication via a “home” AAA/EAP server. Any authentication must pass through this home server, which increases latency. This latency can be reduced, however, by establishing a trust relationship between an EAP peer and a visited domain's AAA/EAP server. Such a trust relationship may be brokered by a home EAP/AAA server, and efficient re-authentication for the EAP peer may be supported locally (i.e., within the visited domain).
- 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.
- 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.
- security material e.g., SRK
- an MN using authentication states—and an AAAn both create an extended master session key (EMSK) that may later be utilized to create a specific root key (SRK).
- the MN may use specific parameters to generate the SRK on its own, and then create a SERVICE_TOKEN_KEY to sign its request for service.
- EMSK extended master session key
- the MN may use specific parameters to generate the SRK on its own, and then create a SERVICE_TOKEN_KEY to sign its request for service.
- an AAAz receives that service request, it forwards the service request to an AAAn, together with usage data that relates to MIPv6 service.
- the AAAn may, after finding the MN's authentication state (including EMSK), verify the MN's authentication. Utilizing usage data sent by the AAAz, and EMSK, the AAAn may: create SRK and SERVICE_TOKEN_KEY; verify MN signature on a service request; or send a confirmation, together with SRK, back to the AAAz.
- FIG. 1 is a diagram depicting an illustrative MIPv6 key hierarchy, resulting from EAP Authentication, according to the present invention
- FIG. 2 depicts an illustrative example of an MIPv6 authorization procedure in accordance with the present invention
- FIG. 3 is a diagram depicting an illustrative embodiment of a MN MIPv6_AUTHORIZATION_OPTION in accordance with the present invention.
- FIG. 4 is a diagram depicting an illustrative embodiment of a Handover Keying (HOKEY) operation in accordance with the present invention.
- HOKEY Handover Keying
- the present invention provides a system for using an authorization token to separate authentication and authorization services.
- the system separates the act of authentication from the act of authorization, and performs authentication or authorization through separate Authentication Authorization and Accounting (AAA) servers.
- a client may first authenticate to an authenticating AAA (AAAN) server, create an authorization token, and then later present the token to a different authorizing AAA (AAAZ) server; while requesting an access for a specific service.
- AAA Authentication Authorization and Accounting
- an AAAN server and a client may create a key (TOKEN_KEY) for signing a generic authorization token. Later, the client (or service equipment acting on behalf of the client) asks an AAAZ for service authorization.
- the client may sign its authorization request with either the TOKEN_KEY as is, or a child key of the TOKEN_KEY tied to a specific service—e.g., a SERVICE_TOKEN_KEY (generation includes service-related information).
- a SERVICE_TOKEN_KEY generation includes service-related information.
- an AAAZ server may contact the AAAN server for the SERVICE_TOKEN_KEY, and verify that the client has been properly authenticated. It may then reach the user profile (based on user's identity), and make a proper authorization decision.
- an authorization token is similar to a movie ticket.
- a user buying a movie ticket may need to show proper identification credentials (e.g., driver's license, credit card) at a ticket counter in order to authenticate their access to a particular resource or service (e.g., sufficient age to enter a theater showing an “R” rated movie).
- a particular resource or service e.g., sufficient age to enter a theater showing an “R” rated movie.
- an Extensible Authentication Protocol is provided for authentication, while a Mobile Internet Protocol (MIP) is provided as a service.
- EAP Extensible Authentication Protocol
- MIP Mobile Internet Protocol
- an operator may need to deploy an AAA_EAP as an authenticating AAA (AAAN) server and an AAA_MIP for a Mobile IP service (AAAZ); or a mobility provider may only deploy an AAA_MIP, while relying on another operator for network access and authentication (AAA_EAP).
- a mobile node with EAP client functionality may authenticate to an AAA_EAP using EAP authentication—either via a Home Agent (HA), or other suitable entity—as a pass-through authenticator. Authentication may be performed by any suitable method. Following a successful authentication, the client and AAA_EAP may generate EAP master session keys (MSK or EMSK), or other shared secret authentication keys. For ease of reference, such secret authentication keys may be referred to as Master Keys (MKs). A MK is available at both AAA_EAP and the client, at the end of an EAP authentication.
- MSK EAP master session keys
- MKs Master Keys
- An AAA server and the client may create a TOKEN_KEY from an MK as follows:
- the client may generate TOKEN_KEY in the same manner as the AAA_EAP server. If there are fields that the client does not have knowledge of, the AAA_EAP server may send information of those fields through an AAA protocol to an AAA client—acting as EAP pass-through—which in turn sends that information to the client through available links.
- the client may also obtain unknown field information through Mobile IP extensions.
- the client may create a service request such as, for example, a registration request, or a binding update in MIP.
- AAA_MIP AAA_MIP
- HA MIP Home Agent
- the authorization extension may include a signature of MIP messaging data—such as a message authentication code (MAC). This may be formed via a relevant registration request, or via binding update data—such as a Mobile node identification, etc.
- a signing key used by a client is a SERVICE_TOKEN_KEY.
- a TOKEN_KEY may be used as a SERVICE_TOKEN_KEY.
- a process for generating a SERVICE_TOKEN_KEY may take the form of:
- An HA upon receiving a MIP message including an authorization extension—may extract signature and include it in an AAA attribute/AVP, together with the MIP service request, to the AAA_MIP.
- the AAA_MIP may, after receiving the request, contact the AAA_EAP to retrieve the SERVICE_TOKEN_KEY; and to verify the MAC submitted by the client. When the MAC signature is verified successfully, the AAA_MIP may authorize MIP service accordingly.
- an AAAz may confirm previous authentication of an MN, and receive usage specific root keys (USRK).
- USRK usage specific root keys
- an MN When an MN is ready to send a service request, it includes an authorization processing parameter—called a network service identifier (NSI)—with the service request to the AAAz, through a service agent (e.g., HA), which acts as an AAA client for AAAz. Since the MN is ready to request MIPv6 service, it has access to usage data.
- a service agent e.g., HA
- EMSK rendered from EAP
- the MN is able to generate a root key for MIPv6 service (MIP6_USRK).
- the MN may also generate a SERVICE_TOKEN_KEY from the MIPv6_USRK to “sign” its request for MIPv6 service.
- the AAAz forwards the service request to the AAAn, along with usage data.
- the AAAn may search for the MN's authentication state (including EMSK), and verify the MN's authentication. Utilizing the usage data sent by AAAz, and EMSK, the AAAn may: generate MIPv6 USRK and SERVICE_TOKEN_KEY; verify the MN signature on the service request; and send a confirmation, along with MIPv6_USRK, back to the AAAz.
- FIG. 1 which illustratively depicts a keying hierarchy diagram 100 —illustrating an authorization process.
- AAAn holds an EMSK and thus—upon receiving service data—may generate MIPv6_USRK.
- SERVICE_TOKEN_KEY and, optionally, Auth_ID may be generated from MIPv6_USRK. This process may take the form of:
- AAAn sends a Diameter EAP answer (DEA) to an AAA client (HA).
- DEA Diameter EAP answer
- AAA client HA
- an MN Upon reception of indication of successful EAP, or IKE configuration messaging, an MN initiates an authorization process—by first generating MIPv6_USRK, an NSI, and a SERVICE_TOKEN_KEY.
- a service request may be a binding update (BU).
- the MN adds an “MN_MIP6_Authorization_option”—a mobility option—to the BU.
- This mobility option comprises an authenticator field (i.e., a MAC) to protect the message and extension from tampering, and to provide assurance of a previous authentication.
- a SERVICE_TOKEN_KEY may be used for creation of a MAC.
- NSI is not used for purposes of identification.
- An MN may, for example, use an NAI extension for this purpose.
- an HA Upon reception of an MIPv6 BU message, an HA—as an AAA client of an AAAz—creates an MIPv6 authorization command for the AAAz.
- the HA inserts data, included in the MN_MIP6v_Authorization_option, inside an AVP for this command.
- An HA also includes User_Name AVP in the MIPv6 authorization request, to identify a particular MN. User_Name AVP carries the same MN identity as that previously used for authentication.
- the AAAz For the MIPv6 authorization request message, the AAAz first ensures that the MN is previously authorized. The AAAz investigates location of the AAAn that authenticated the MN, based on the MIPv6 Authorization Request, and sends a “Mobile IPv6 Key and verification request” (MKVR) command to the AAAn.
- MKVR Mobile IPv6 Key and verification request
- This command may serve several purposes, including: an AAAz requesting an AAAn to verify a MAC signature, and thereby assure AAAz that an MN has already been authenticated; and to request creation a MIP6_USRK for usage at AAAz.
- the AAAn needs usage data for MIPv6 (as found in [MIP USRK]) to be able to calculate MIP6_USRK.
- an AAAz must also include usage data—required for creation of MIP6_USRK—to the AAAn [USRK].
- Usage data is included inside a “MIP6_Usage_data” AVP. Transport of usage data to AAAn is important, since AAAn (AAA_EAP) has the EMSK, while AAAn may not have access to Mobile IPv6 related data.
- AAAz may get part of usage data from the HA or MN.
- MKVA includes an Authorization_Result AVP indicating the failure.
- an AAAz may create other MIP6 child keys, using the received MIP6_USRK, and authorize the MN for Mobile IPv6 service—by sending a MIPv6 authorization answer to the AAA client (HA)
- MN MIPv6_AUTHORIZATION_OPTION is an extension for MIPv6, and it comprises a service authorization request—which, for MIPv6, is a binding update sent to the HA. The option is designed to facilitate mobility and the MAC signature.
- FIG. 3 presents a diagram 300 representing an embodiment of a MN MIPv6_AUTHORIZATION_OPTION in accordance with the present invention.
- type is assigned by IANA.
- the length of the option may depend on the length of a MAC.
- MN_ID is the same MN identifier used for previous authentication, and so may seem minimally redundant.
- Inclusion of a service type field within a MIPv6 option may also seem redundant. However, such inclusions may make conversion of such a MIPv6 option to other AVPs less complicated.
- MAC is an authenticator field for this option, and may be calculated as follows:
- the present invention thus provides an end client the ability to use an initial EAP authentication procedure to create an authorization token on its own, for each service request.
- the present invention is—for purposes of illustration and explanation—described above in relation to MIP, it is not limited exclusively to MIP, and may be applied to other service technologies or applications.
- the system of the present invention also provides ability for an AAA_EAP to interact with authorization processes, without advance notification of the specific nature of a service being authorized.
- the system of the present invention provides EAP key hierarchy, and generates specific authorization keys from EAP—hiding MKs from all entities other than an AAA_EAP and clients.
- the system of the present invention utilizes MIP extensions to carry authorization token data from a mobile node to an AAAz, through an HA, and uses an AAA protocol attribute to carry authorization token data over an AAA protocol.
- the system of the present invention eliminates intervention of intermediary service equipments—such as MIP HA—in a verification process. This eliminates security issues related to an HA, such as an HA launching a “man in middle” attack.
- the system of the present invention also eliminates the need for an HA to function as an EAP pass-through authenticator, during an initial EAP authentication. According to the present invention, an HA does not have to be part of an authentication infrastructure.
- HOKEY Handover Keying
- an MN 402 authenticates to an EAP Server (AAAn) 404 using EAP. Both MN 402 and AAAn 404 generate EMSK. MN 402 initiates a request for a key management service (e.g., key distribution to 3rd party, session extension) by creating a key (SRK) from EMSK; and including a signature with the SRK (and other information) as an extension to a request message to server 404 . This signature provides proof of possession of EMSK, which establishes a valid prior authentication.
- a key management service e.g., key distribution to 3rd party, session extension
- SRK key distribution to 3rd party, session extension
- This signature provides proof of possession of EMSK, which establishes a valid prior authentication.
- An AAAz server 406 a distinct fulfillment server (i.e., continued service or third party) which may be an AAA server in a home or visited domain, or an AAA server collocated with server 404 —creates a request to server 404 for verification of the signature, and may transmit service related data from MN 402 .
- Server 404 generates SRK from EMSK—and, possibly, usage data from server 406 —and verifies the signature.
- Server 404 may then create a handover root key (HRK), and other domain and usage-related keys, and transmit those back to server 406 .
- Server 404 may, alternatively, send HRK to server 406 —and allow it to generate SRK and verify the request itself.
- server 406 authorizes MN 402 —and its associated authenticator—for service; and creates and provides keys for the authenticator.
- the system of the present invention thus provides the ability to use an initial EAP authentication procedure to generate or provide authorization tokens to third parties, or for session extension(s).
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
- This application claims the priority benefit of U.S. Provisional Application No. 60/867,377, filed Nov. 27, 2006.
- 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.
- 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 service equipment to see if service may be granted.
- As diverse broadband access technologies are increasingly developed and deployed, revenue margins for access providers tend to decrease. Diversity of access technologies also dictates a need for access-independent application and service offerings—such that a service-only provider can deploy a single service-architecture for any user, regardless of underlying access technology, while co-existing with access providers providing only connectivity. Mobile Internet Protocol v6 (MIPv6) operational development is, for example, considering scenarios where a mobility service provider is separate and distinct from an access service provider. Different providers will naturally use different Authenticating, Authentication, and Authorization (AAA) servers, and possibly different AAA infrastructure, to control and manage resource usage and users.
- Service provider equipment and infrastructure may be different from network access equipment. For instance, a MIP Home Agent (HA) may be part of a service provider network, while a network access server/Extensible Authentication Protocol (EAP) authenticator may be part of a network access provider. A separation of signaling path for authorization and authentication may be needed in such a configuration.
- Conventional systems have typically used the same authentication and authorization credentials. 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. The less that authentication credentials are used, the better—from a security standpoint. Separation may be especially beneficial since an authentication procedure may typically establish a set of security associations with network boundaries, and later the authorization signaling may be performed over this secure channel using less security-intense authorization credentials.
- By way of illustration, consider an analogy of watching a movie at a movie theater. At least for the time being, watching a movie requires only a movie ticket. Showing a movie ticket does not require showing a drivers license, particularly when a person may have already shown a drivers license in conjunction with paying for the ticket (e.g., with a credit card).
- Another approach is being developed in the Internet Engineering Task force (IETF) to address issues arising in conjunction with this new trend—one where no proof of prior authentication is provided to an authorizing server. This approach is obviously subject to a number of security concerns, however.
- By way of illustration, Kerberos is a conventional technology for performing authentication and authorization separately. Using Kerberos, a token is generated in an authentication process, and is used for authorization. However, both a service server and a client receive keys through a Key Distribution Center (KDC), via secure transport. No keys are transported between the service server and the client. A token is service specific, and is encrypted with a key, known only to the service server. Retrieval of the token requires additional roundtrips between a client and the KDC server.
- Another emerging trend is the use of extensible authentication protocol (EAP) for authentication of mobile nodes at AAA servers. Key generation capabilities of EAP servers [EAPKEYING] [USRK], combined with the addition of EAP as an authentication method for IKEv2 [IKEv2], and use of backend Diameter servers and infrastructure [RFC4072], have made EAP a popular authentication method—as compared to customized authentication and key management mechanisms defined for MIPv4 or Kerberos. Once EAP authentication is performed successfully, and EAP master session keys (MSK and EMSK) are generated, a server will be able to use these keys to generate root keys for a variety of uses—such as MIPv6 [MIP-USRK].
- Since MIPv6 operation requires bootstrapping of various parameters—such as home address, home agent address, and IPsec security associations—efforts in the IETF are underway to perform such bootstrapping through AAA infrastructure. In more recent efforts, the IPSec association required for MIPv6 operation between a mobile node (MN) and a home agent (HA) is established using IKEv2. To get around the need for pre-shared key for IKEv2 authentication, the MN authenticates through a MIP home agent (HA) to a backend AAAn, using EAP. Thus, EAP authentication is done as part of an IKEv2 exchange. However, the authentication of an MN is only part of the MIP service establishment procedure. Once the MN completes the IKEv2-EAP authentication, and establishes an IPsec channel with the HA, it still needs to be authorized for use MIP service. This typically means that an authorization server (usually also an AAA server) needs to perform the act of authorization.
- The recent trend on separation of access service from mobility service, leads to newer design that separates the act of EAP authentication from the act of authorization for MIPv6 service. Under this paradigm, a peer and AAA client first run an EAP authentication with an authenticating AAA server—referred to as AAA-EAP or AAAn. The peer then requests MIPv6 service authorization from an authorizing server—referred to as MIPAAA or AAAz. It has been suggested that there may be scenarios where AAAn and AAAz are logically or physically different servers, and may not have access to the same database. A number of security and operation considerations arise in such scenarios.
- 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. However an AAAn, as an entity performing EAP, is the only entity allowed to cache EMSK—since EMSK is not allowed to be transported outside AAAn [EAPKEYING]. This means that root keys for other usages—such as MIPv6_USRK (Mobile IPv6 usage specific root key)—can only be generated at and by the AAAn. In contrast, MIP service is authorized only at AAAz. This means that the MIPv6-USRK must be created only after such authorization, and be accessible to the AAAz for generation of other MIPv6 security keys. Furthermore, generation of MIPv6_USRK requires access to other “usage data” specific for Mobile IPv6; which is typically not available at the AAAn. Thus, the AAAz must make the “usage data” available to the AAAn, and request MIPv6_USRK from the AAAn, in order to be able to generate further MIPv6 keys.
- In further consideration, most traditional authorization frameworks simply do not have any special credential-based procedure for authorization. An authorization decision itself is performed based a user profile available at a server—not based on a credential presented by a client as proof for a right of access to service. As long as the client is previously authenticated, the client's identity is used against its profile in a database. Under this scheme, using the movie theater analogy, a person walks into a movie theater and—instead of paying for a ticket as a proof of right to view a movie—the person simply shows some identification. Based on the person's identity, and upon some movie theater membership list—the person is allowed to just walk into the theater without a ticket.
- However, such separation of authorization from authentication means that an authorizing server (AAAz) needs an assurance of previous authentication from an authenticating server (AAAn). 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. A rogue MN (or even an AAA client) could potentially use a spoofed identity (for a legitimate subscriber) to send service requests on behalf of a legitimate MN, and have charges for rendered services transferred to the legitimate MN. 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. Any proxy or middle man (including the HA itself) on the path from HA to the AAAz can modify a service request. So it is important that when AAAz receives a service request from an MN, it can confirm that the MN has already been authenticated by an AAAn, and is using the same authenticated identity for its service request—so that the AAAz can authorize service for a legitimate MN.
- Still other applications, such as Handover Keying (HOKEY), provide useful illustration of this technology. In most conventional HOKEY applications, deployments of EAP in wireless networks employ an authenticator in pass-through mode (typically located at an edge) coupled with a backend AAA/EAP server. A number of conventional EAP systems generate an MSK and an EMSK. 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. Different EAP lower layers make use of the MSK differently. A common usage for MSK is to derive Transient Session Keys (TSKs)—providing access link security in networks (e.g., IEEE 802.11i, IEEE 802.16e)—although some lower layers (e.g., IKEv2) use MSK for other purposes.
- Extensions to current EAP key framework will be needed in the future to facilitate inter-authenticator handover and roaming. There are a number of issues that may arise in relation to EAP keying. For example, inter-authenticator handovers currently require re-execution of EAP authentication, even though the same EAP authentication server is used. Handover scenarios may vary considerably in their fundamental assumptions and functional constraints. In scenarios where, for example, hosts remain connected during a handover period, EAP authentication does not need to be in the critical path for handover. 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. Although some conventional EAP systems do provide re-authentication mechanisms, more consistent, low-latency, EAP-method-independent, re-authentication mechanisms are needed. Also, an EAP-generated EMSK key may be used as a root of a cryptographic key hierarchy—where keys in the hierarchy are then used in various ways to provide necessary security services. In order to ensure that different keys derived from an EMSK are cryptographically separate, and that such key derivations are coordinated in an acceptable manner, there is a need to clearly specify hierarchy parameters—such as topology for the key hierarchy, top of the topology, and guidelines for child key derivations.
- When wireless networks employ AAA infrastructures, cross-domain roaming is typically handled by inter-domain authentication via a “home” AAA/EAP server. Any authentication must pass through this home server, which increases latency. This latency can be reduced, however, by establishing a trust relationship between an EAP peer and a visited domain's AAA/EAP server. Such a trust relationship may be brokered by a home EAP/AAA server, and efficient re-authentication for the EAP peer may be supported locally (i.e., within the visited domain).
- In consideration of all of this, there is a need for a system where authentication and authorization are performed separately and securely, and where a reliable trust mechanism for such operation is also provided. There is also a need for a system performing authentication and authorization separately that provides Authentication Authorization and Accounting (AAA) services with high performance and low complexity.
- 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.
- 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.
- Following a successful EAP authentication, and prior to a service request, an MN—using authentication states—and an AAAn both create an extended master session key (EMSK) that may later be utilized to create a specific root key (SRK). The MN may use specific parameters to generate the SRK on its own, and then create a SERVICE_TOKEN_KEY to sign its request for service. When the MN is ready to send a service request, it includes a signature using SERVICE_TOKEN_KEY and transmits the request. Once an AAAz receives that service request, it forwards the service request to an AAAn, together with usage data that relates to MIPv6 service. The AAAn may, after finding the MN's authentication state (including EMSK), verify the MN's authentication. Utilizing usage data sent by the AAAz, and EMSK, the AAAn may: create SRK and SERVICE_TOKEN_KEY; verify MN signature on a service request; or send a confirmation, together with SRK, back to the AAAz.
- The following description and drawings set forth in detail a number of illustrative embodiments of the invention. These embodiments are indicative of but a few of the various ways in which the present invention may be utilized.
- For a more complete understanding of the present disclosure and its advantages, reference is now made to the following description taken in conjunction with the accompanying drawings, in which like reference numerals represent like parts:
-
FIG. 1 is a diagram depicting an illustrative MIPv6 key hierarchy, resulting from EAP Authentication, according to the present invention; -
FIG. 2 depicts an illustrative example of an MIPv6 authorization procedure in accordance with the present invention; -
FIG. 3 is a diagram depicting an illustrative embodiment of a MN MIPv6_AUTHORIZATION_OPTION in accordance with the present invention; and -
FIG. 4 is a diagram depicting an illustrative embodiment of a Handover Keying (HOKEY) operation in accordance with the present invention. - The following discussion is presented to enable a person skilled in the art to make and use the invention. The general principles described herein may be applied to embodiments and applications other than those detailed below without departing from the spirit and scope of the present invention as defined herein. The present invention is not intended to be limited to the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.
- The present invention provides a system for using an authorization token to separate authentication and authorization services. The system separates the act of authentication from the act of authorization, and performs authentication or authorization through separate Authentication Authorization and Accounting (AAA) servers. A client may first authenticate to an authenticating AAA (AAAN) server, create an authorization token, and then later present the token to a different authorizing AAA (AAAZ) server; while requesting an access for a specific service.
- Following a successful authentication, an AAAN server and a client may create a key (TOKEN_KEY) for signing a generic authorization token. Later, the client (or service equipment acting on behalf of the client) asks an AAAZ for service authorization. The client may sign its authorization request with either the TOKEN_KEY as is, or a child key of the TOKEN_KEY tied to a specific service—e.g., a SERVICE_TOKEN_KEY (generation includes service-related information). When an AAAZ server receives such a request, it may contact the AAAN server for the SERVICE_TOKEN_KEY, and verify that the client has been properly authenticated. It may then reach the user profile (based on user's identity), and make a proper authorization decision.
- Using the earlier analogy of movie tickets, an authorization token is similar to a movie ticket. A user buying a movie ticket may need to show proper identification credentials (e.g., driver's license, credit card) at a ticket counter in order to authenticate their access to a particular resource or service (e.g., sufficient age to enter a theater showing an “R” rated movie). Once the user has thus been properly authenticated, they are granted authorization (e.g., a movie ticket) to gain access. Once the ticket is purchased, obtaining access (e.g., entering into the theater) only requires establishing authorization (e.g., showing the ticket), but not authentication.
- In certain embodiments of the present invention, an Extensible Authentication Protocol (EAP) is provided for authentication, while a Mobile Internet Protocol (MIP) is provided as a service. In some embodiments, for example, an operator may need to deploy an AAA_EAP as an authenticating AAA (AAAN) server and an AAA_MIP for a Mobile IP service (AAAZ); or a mobility provider may only deploy an AAA_MIP, while relying on another operator for network access and authentication (AAA_EAP).
- A mobile node with EAP client functionality may authenticate to an AAA_EAP using EAP authentication—either via a Home Agent (HA), or other suitable entity—as a pass-through authenticator. Authentication may be performed by any suitable method. Following a successful authentication, the client and AAA_EAP may generate EAP master session keys (MSK or EMSK), or other shared secret authentication keys. For ease of reference, such secret authentication keys may be referred to as Master Keys (MKs). A MK is available at both AAA_EAP and the client, at the end of an EAP authentication.
- An AAA server and the client may create a TOKEN_KEY from an MK as follows:
-
- TOKEN_KEY=PRF(MK, key generation data);
where PRF (Pseudo Random Function) may comprise a one way cryptographic function, or other function or operation that renders efforts to deduct input data from output data nearly impossible. The key generation data may include: an ASCII label, such as “Authorization key generation”; client identity; AAA_EAP server identity; key length; or other optional fields. Both client and AAA_EAP must have access to key generation data, so that they may both create TOKEN_KEY.
- TOKEN_KEY=PRF(MK, key generation data);
- Upon receipt of an EAP_Success message, the client may generate TOKEN_KEY in the same manner as the AAA_EAP server. If there are fields that the client does not have knowledge of, the AAA_EAP server may send information of those fields through an AAA protocol to an AAA client—acting as EAP pass-through—which in turn sends that information to the client through available links. The client may also obtain unknown field information through Mobile IP extensions. The client may create a service request such as, for example, a registration request, or a binding update in MIP. Since a service request may be forwarded to AAA_MIP (AAAZ)—possibly through a MIP Home Agent (HA)—the client may include a MIP extension (i.e., authorization extension), to verify that the client has been authenticated to that AAA_EAP.
- The authorization extension (MIP) may include a signature of MIP messaging data—such as a message authentication code (MAC). This may be formed via a relevant registration request, or via binding update data—such as a Mobile node identification, etc. A signing key used by a client is a SERVICE_TOKEN_KEY. For the sake of simplicity, a TOKEN_KEY may be used as a SERVICE_TOKEN_KEY. A process for generating a SERVICE_TOKEN_KEY may take the form of:
-
- SERVICE_TOKEN_KEY=PRF(TOKEN_KEY, service-data);
where service-data is data related to services being requested. In this example, service-data is data related to MIP services.
- SERVICE_TOKEN_KEY=PRF(TOKEN_KEY, service-data);
- An HA—upon receiving a MIP message including an authorization extension—may extract signature and include it in an AAA attribute/AVP, together with the MIP service request, to the AAA_MIP. The AAA_MIP may, after receiving the request, contact the AAA_EAP to retrieve the SERVICE_TOKEN_KEY; and to verify the MAC submitted by the client. When the MAC signature is verified successfully, the AAA_MIP may authorize MIP service accordingly.
- For purposes of explanation and illustration, the present invention is described in greater detail hereinafter in relation to a MIPv6 application. In order to sufficiently tie authentication and authorization procedures between potentially different AAA servers, an AAAz may confirm previous authentication of an MN, and receive usage specific root keys (USRK). When an MN is ready to send a service request, it includes an authorization processing parameter—called a network service identifier (NSI)—with the service request to the AAAz, through a service agent (e.g., HA), which acts as an AAA client for AAAz. Since the MN is ready to request MIPv6 service, it has access to usage data. Using an EMSK rendered from EAP, the MN is able to generate a root key for MIPv6 service (MIP6_USRK). The MN may also generate a SERVICE_TOKEN_KEY from the MIPv6_USRK to “sign” its request for MIPv6 service.
- Once the AAAz receives the service request, it forwards the service request to the AAAn, along with usage data. The AAAn may search for the MN's authentication state (including EMSK), and verify the MN's authentication. Utilizing the usage data sent by AAAz, and EMSK, the AAAn may: generate MIPv6 USRK and SERVICE_TOKEN_KEY; verify the MN signature on the service request; and send a confirmation, along with MIPv6_USRK, back to the AAAz.
- One embodiment of a keying hierarchy is described in reference to
FIG. 1 , which illustratively depicts a keying hierarchy diagram 100—illustrating an authorization process. As noted, AAAn holds an EMSK and thus—upon receiving service data—may generate MIPv6_USRK. SERVICE_TOKEN_KEY and, optionally, Auth_ID may be generated from MIPv6_USRK. This process may take the form of: -
- SERVICE_TOKEN_KEY=PRF (MIP6 USRK, “service token key derivation” |MN_ID|AAAz_ID|Service_type|length);
where the length of SERVICE_TOKEN_KEY is 128 bits. MN_ID and AAAz_ID identify the two entities who share the key.
- SERVICE_TOKEN_KEY=PRF (MIP6 USRK, “service token key derivation” |MN_ID|AAAz_ID|Service_type|length);
- Referring now to
FIG. 2 , a depiction of one embodiment of aMIPv6 authorization procedure 200 in accordance with the present invention is illustrated. Inprocedure 200, after a successful authentication (i.e., EAP is utilized for authentication), AAAn sends a Diameter EAP answer (DEA) to an AAA client (HA). Upon reception of indication of successful EAP, or IKE configuration messaging, an MN initiates an authorization process—by first generating MIPv6_USRK, an NSI, and a SERVICE_TOKEN_KEY. - In the example of a MIPv6 application, a service request may be a binding update (BU). The MN adds an “MN_MIP6_Authorization_option”—a mobility option—to the BU. This mobility option comprises an authenticator field (i.e., a MAC) to protect the message and extension from tampering, and to provide assurance of a previous authentication.
- A SERVICE_TOKEN_KEY, derived from MIPv6-USRK, may be used for creation of a MAC. In such instances, NSI is not used for purposes of identification. In fact, the same identity used for authentication to AAAn may be used again. An MN may, for example, use an NAI extension for this purpose. Upon reception of an MIPv6 BU message, an HA—as an AAA client of an AAAz—creates an MIPv6 authorization command for the AAAz. The HA inserts data, included in the MN_MIP6v_Authorization_option, inside an AVP for this command. An HA also includes User_Name AVP in the MIPv6 authorization request, to identify a particular MN. User_Name AVP carries the same MN identity as that previously used for authentication.
- For the MIPv6 authorization request message, the AAAz first ensures that the MN is previously authorized. The AAAz investigates location of the AAAn that authenticated the MN, based on the MIPv6 Authorization Request, and sends a “Mobile IPv6 Key and verification request” (MKVR) command to the AAAn. This command may serve several purposes, including: an AAAz requesting an AAAn to verify a MAC signature, and thereby assure AAAz that an MN has already been authenticated; and to request creation a MIP6_USRK for usage at AAAz.
- The AAAn needs usage data for MIPv6 (as found in [MIP USRK]) to be able to calculate MIP6_USRK. Thus, an AAAz must also include usage data—required for creation of MIP6_USRK—to the AAAn [USRK]. Usage data is included inside a “MIP6_Usage_data” AVP. Transport of usage data to AAAn is important, since AAAn (AAA_EAP) has the EMSK, while AAAn may not have access to Mobile IPv6 related data. AAAz may get part of usage data from the HA or MN.
- After receiving a MKVR command from a AAAz, the AAAn performs several checks. The AAAn looks for key material (EMSK) stored for the MN, proceeds with creating MIP6_USRK using EMSK, and then generates SERVICE_TOKEN_KEY to check the MN signature. If the signature verification succeeds, the AAAn sends a MIPv6 key and verification answer (MKVA) back to the AAAz. This command verifies that MN has already been authenticated by the AAAn, so that AAAz can authorize MN for MIPv6 service, and includes the MIP6_USRK for AAAz usage. Therefore, MIP6_USRK AVP must be encrypted, using a previously established AAAn-AAAz security association (e.g. an AAAn-AAAz key encryption key). In the event that verification fails, MKVA includes an Authorization_Result AVP indicating the failure. When it receives an MKVA command, an AAAz may create other MIP6 child keys, using the received MIP6_USRK, and authorize the MN for Mobile IPv6 service—by sending a MIPv6 authorization answer to the AAA client (HA)
- Upon receiving a MIPv6 authorization answer (MAA) message, an HA my obtain authorization result and MIP6 related keys. If authorization fails, the HA notifies the MN in the binding acknowledgement message. MN MIPv6_AUTHORIZATION_OPTION is an extension for MIPv6, and it comprises a service authorization request—which, for MIPv6, is a binding update sent to the HA. The option is designed to facilitate mobility and the MAC signature.
- This is illustratively depicted in
FIG. 3 , which presents a diagram 300 representing an embodiment of a MN MIPv6_AUTHORIZATION_OPTION in accordance with the present invention. Here, type is assigned by IANA. The length of the option may depend on the length of a MAC. MN_ID is the same MN identifier used for previous authentication, and so may seem minimally redundant. Inclusion of a service type field within a MIPv6 option may also seem redundant. However, such inclusions may make conversion of such a MIPv6 option to other AVPs less complicated. - In instances where bandwidth limitation for links between an MN and an HA is of concern, this field may be dropped and added by the HA to a Diameter AVP. The length of “Service Type” is adaptable—based upon a number of systems factors, and emerging industry definitions and standards (e.g., IETF USRK definition efforts). MAC is an authenticator field for this option, and may be calculated as follows:
-
- MAC=First (128, HMAC_SHA1 (SERVICE_TOKEN KEY, Authorization data);
where - Authorization data=(optional data|MN_ID|Service_type).
Note that optional data may include AAAn realm information, and thereby serve as an indicator of the AAA server that authenticated the MN, and possible generated parts of Auth_ID.
- MAC=First (128, HMAC_SHA1 (SERVICE_TOKEN KEY, Authorization data);
- The present invention thus provides an end client the ability to use an initial EAP authentication procedure to create an authorization token on its own, for each service request. Although the present invention is—for purposes of illustration and explanation—described above in relation to MIP, it is not limited exclusively to MIP, and may be applied to other service technologies or applications.
- The system of the present invention also provides ability for an AAA_EAP to interact with authorization processes, without advance notification of the specific nature of a service being authorized. The system of the present invention provides EAP key hierarchy, and generates specific authorization keys from EAP—hiding MKs from all entities other than an AAA_EAP and clients. The system of the present invention utilizes MIP extensions to carry authorization token data from a mobile node to an AAAz, through an HA, and uses an AAA protocol attribute to carry authorization token data over an AAA protocol. The system of the present invention eliminates intervention of intermediary service equipments—such as MIP HA—in a verification process. This eliminates security issues related to an HA, such as an HA launching a “man in middle” attack. The system of the present invention also eliminates the need for an HA to function as an EAP pass-through authenticator, during an initial EAP authentication. According to the present invention, an HA does not have to be part of an authentication infrastructure.
- Certain aspects of the present invention are further described in reference to the operation of a Handover Keying (HOKEY) based
system 400, as illustratively depicted inFIG. 4 . As previously noted, future extensions to conventional HOKEY deployments of EAP in wireless networks will likely be needed to facilitate inter-authenticator handover and roaming. The operation ofsystem 400 according to the present invention provides a secure and efficient solution to those needs. - In the HOKEY embodiment illustrated in
FIG. 4 , anMN 402 authenticates to an EAP Server (AAAn) 404 using EAP. BothMN 402 andAAAn 404 generate EMSK.MN 402 initiates a request for a key management service (e.g., key distribution to 3rd party, session extension) by creating a key (SRK) from EMSK; and including a signature with the SRK (and other information) as an extension to a request message toserver 404. This signature provides proof of possession of EMSK, which establishes a valid prior authentication. - An
AAAz server 406—a distinct fulfillment server (i.e., continued service or third party) which may be an AAA server in a home or visited domain, or an AAA server collocated withserver 404—creates a request toserver 404 for verification of the signature, and may transmit service related data fromMN 402.Server 404 generates SRK from EMSK—and, possibly, usage data fromserver 406—and verifies the signature.Server 404 may then create a handover root key (HRK), and other domain and usage-related keys, and transmit those back toserver 406.Server 404 may, alternatively, send HRK toserver 406—and allow it to generate SRK and verify the request itself. Once a request is verified,server 406 authorizesMN 402—and its associated authenticator—for service; and creates and provides keys for the authenticator. The system of the present invention thus provides the ability to use an initial EAP authentication procedure to generate or provide authorization tokens to third parties, or for session extension(s). - The previous description of the disclosed embodiments is provided to enable those skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art and generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims (24)
1. A method of separating authentication and authorization services in a communications system, comprising the steps of:
authenticating a client node to an authenticating server utilizing extensible authentication protocol;
generating an authorization token; and
authorizing services rendered to the client node via an authorizing server, based upon information in the authorization token.
2. The method of claim 1 , further comprising distributing the authorization token by which a client is capable of signing its service requests to an authorization server.
3. The method of claim 2 , wherein the client, following a successful authentication, signs service authorization requests towards the authorizing server.
4. The method of claim 2 , wherein the authorizing server authorizes the client service request, based upon the existence of the client signature, free from the authorizing server authenticating client identity.
5. The method of claim 4 , wherein the authorizing server authorizes a client service request for fulfillment by a continued service server.
6. The method of claim 4 , wherein the authorizing server authorizes a client service request for fulfillment by a third party server.
7. A method by which a Handover Keying authorization request for a client, and authentication of the client, comprising the steps of:
authenticating a client node to an authenticating server utilizing extensible authentication protocol;
generating an authorization token; and
authorizing services rendered to the client node via an authorizing server, based upon information in the authorization token.
8. The method of claim 7 , wherein the authorizing server is different from the authenticating AAA server, in at least one logical or physical aspect.
9. The method of claim 7 , further comprising distributing the authorization token by which a client is capable of signing its service requests to an authorizing server.
10. The method of claim 7 , wherein the client, following a successful authentication, signs service authorization requests towards the authorizing server.
11. The method of claim 7 , wherein the authorizing server authorizes the client service request, based upon the existence of the client signature, free from the authorizing server authenticating client identity.
12. The method of claim 11 , wherein the authorizing server authorizes a client service request for fulfillment by a continued service server.
13. The method of claim 11 , wherein the authorizing server authorizes a client service request for fulfillment by a third party server.
14. The method of claim 7 , wherein the authorization token is derived from an extensible authentication protocol master session key.
15. The method of claim 7 , wherein the authorization token comprises a shared secret authentication key between the authorizing server and the client node.
16. The method of claim 14 , wherein the extensible authentication protocol master session key is generated after successful extensible authentication protocol authentication.
17. The method of claim 14 , wherein the authorization token is delivered from the authentication server to the authorization server.
18. The method of claim 14 , wherein the authorization token is encrypted for delivery to the authorization server.
19. A communications system comprising:
an authenticating network component;
an authorizing network component; and
a client network component, adapted to:
exchange authentication messages with the authenticating network component utilizing extensible authentication protocol;
generate an authorization token; and
transfer the authorization token to the authorizing server to request a service.
20. The system of claim 19 , wherein the service is Handover Keying service.
21. A client network device for use in a communications system, comprising:
a first component adapted to exchange authentication messages with an authenticating network component, utilizing extensible authentication protocol;
a second component adapted to generate an authorization token; and
a third component adapted to transfer the authorization token to the authorizing server to request a service.
22. The device of claim 21 , wherein the service is Handover Keying service.
23. An authenticating network device for use in a communications system, comprising:
a first component adapted to receive authentication messages from a client network device, utilizing extensible authentication protocol;
a second component adapted to generate an authorization token;
a third component adapted to receive a service authentication message from a network service device; and
a fourth component adapted to authenticate the service authentication message utilizing the authorization token.
24. The device of claim 23 , wherein the service authentication message is for Handover Keying service.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/938,048 US20080178274A1 (en) | 2006-11-27 | 2007-11-09 | System for using an authorization token to separate authentication and authorization services |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US86737706P | 2006-11-27 | 2006-11-27 | |
US11/938,048 US20080178274A1 (en) | 2006-11-27 | 2007-11-09 | System for using an authorization token to separate authentication and authorization services |
Publications (1)
Publication Number | Publication Date |
---|---|
US20080178274A1 true US20080178274A1 (en) | 2008-07-24 |
Family
ID=39467442
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/838,377 Active 2029-11-24 US8539559B2 (en) | 2006-11-27 | 2007-08-14 | System for using an authorization token to separate authentication and authorization services |
US11/938,048 Abandoned US20080178274A1 (en) | 2006-11-27 | 2007-11-09 | System for using an authorization token to separate authentication and authorization services |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/838,377 Active 2029-11-24 US8539559B2 (en) | 2006-11-27 | 2007-08-14 | System for using an authorization token to separate authentication and authorization services |
Country Status (4)
Country | Link |
---|---|
US (2) | US8539559B2 (en) |
EP (1) | EP2082539A4 (en) |
CN (1) | CN101536438B (en) |
WO (1) | WO2008064589A1 (en) |
Cited By (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060078119A1 (en) * | 2004-10-11 | 2006-04-13 | Jee Jung H | Bootstrapping method and system in mobile network using diameter-based protocol |
US20080127317A1 (en) * | 2006-11-27 | 2008-05-29 | Futurewei Technologies, Inc. | System for using an authorization token to separate authentication and authorization services |
US20080168537A1 (en) * | 2007-01-09 | 2008-07-10 | Futurewei Technologies, Inc. | Service Authorization for Distributed Authentication and Authorization Servers |
US20080229107A1 (en) * | 2007-03-14 | 2008-09-18 | Futurewei Technologies, Inc. | Token-Based Dynamic Key Distribution Method for Roaming Environments |
US20090031138A1 (en) * | 2007-05-14 | 2009-01-29 | Futurewei Technologies, Inc. | Method and system for authentication confirmation using extensible authentication protocol |
US20100281523A1 (en) * | 2007-12-27 | 2010-11-04 | Yunbo Pan | Method and system for negotiating network service |
US20110107085A1 (en) * | 2009-10-30 | 2011-05-05 | Mizikovsky Semyon B | Authenticator relocation method for wimax system |
WO2014168638A1 (en) * | 2013-04-12 | 2014-10-16 | Globoforce Limited | System and method for mobile single sign-on integration |
WO2015171625A1 (en) * | 2014-05-05 | 2015-11-12 | Visa International Service Association | System and method for token domain control |
WO2016014079A1 (en) * | 2014-07-25 | 2016-01-28 | Hewlett-Packard Development Company, L.P. | Constraining authorization tokens via filtering |
US20180077139A1 (en) * | 2012-05-14 | 2018-03-15 | Nec Europe Ltd. | Method and system for accessing service/data of a first network from a second network for service/data access via the second network |
US10110595B2 (en) | 2015-03-16 | 2018-10-23 | Convida Wireless, Llc | End-to-end authentication at the service layer using public keying mechanisms |
US10129031B2 (en) * | 2014-10-31 | 2018-11-13 | Convida Wireless, Llc | End-to-end service layer authentication |
US10305900B2 (en) * | 2013-10-15 | 2019-05-28 | Telefonaktiebolaget Lm Ericsson (Publ) | Establishing a secure connection between a master device and a slave device |
US10644875B2 (en) | 2016-04-28 | 2020-05-05 | International Business Machines Corporation | Pre-authorization of public key infrastructure |
Families Citing this family (39)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
FI20070157A0 (en) * | 2007-02-23 | 2007-02-23 | Nokia Corp | Fast authentication of update messages with key differentiation on mobile IP systems |
US8667151B2 (en) * | 2007-08-09 | 2014-03-04 | Alcatel Lucent | Bootstrapping method for setting up a security association |
US20100088752A1 (en) * | 2008-10-03 | 2010-04-08 | Vikram Nagulakonda | Identifier Binding for Automated Web Processing |
KR101556906B1 (en) * | 2008-12-29 | 2015-10-06 | 삼성전자주식회사 | Method for handover by pre-authenticating between heterogeneous wireless communication systems |
US20110030039A1 (en) * | 2009-07-31 | 2011-02-03 | Eric Bilange | Device, method and apparatus for authentication on untrusted networks via trusted networks |
US8555361B2 (en) * | 2010-02-26 | 2013-10-08 | Motorola Mobility Llc | Dynamic cryptographic subscriber-device identity binding for subscriber mobility |
EP2384040B1 (en) * | 2010-04-29 | 2013-12-25 | BlackBerry Limited | Authentication server and method for granting tokens |
US8898453B2 (en) | 2010-04-29 | 2014-11-25 | Blackberry Limited | Authentication server and method for granting tokens |
EP2604017B1 (en) * | 2010-08-10 | 2017-10-04 | Google Technology Holdings LLC | System and method for cognizant transport layer security |
US9060273B2 (en) | 2012-03-22 | 2015-06-16 | Blackberry Limited | Authentication server and methods for granting tokens comprising location data |
US9438598B2 (en) | 2013-02-15 | 2016-09-06 | Verizon Patent And Licensing Inc. | Securely updating information identifying services accessible via keys |
US9154482B2 (en) * | 2013-02-15 | 2015-10-06 | Verizon Patent And Licensing Inc. | Secure access credential updating |
CN103491084B (en) * | 2013-09-17 | 2016-06-15 | 天脉聚源(北京)传媒科技有限公司 | The authentication method of a kind of client and device |
US11615401B1 (en) | 2014-04-30 | 2023-03-28 | Wells Fargo Bank, N.A. | Mobile wallet authentication systems and methods |
US11461766B1 (en) | 2014-04-30 | 2022-10-04 | Wells Fargo Bank, N.A. | Mobile wallet using tokenized card systems and methods |
US11748736B1 (en) | 2014-04-30 | 2023-09-05 | Wells Fargo Bank, N.A. | Mobile wallet integration within mobile banking |
US11288660B1 (en) | 2014-04-30 | 2022-03-29 | Wells Fargo Bank, N.A. | Mobile wallet account balance systems and methods |
US9652770B1 (en) | 2014-04-30 | 2017-05-16 | Wells Fargo Bank, N.A. | Mobile wallet using tokenized card systems and methods |
US11610197B1 (en) | 2014-04-30 | 2023-03-21 | Wells Fargo Bank, N.A. | Mobile wallet rewards redemption systems and methods |
US10997592B1 (en) * | 2014-04-30 | 2021-05-04 | Wells Fargo Bank, N.A. | Mobile wallet account balance systems and methods |
US10212136B1 (en) | 2014-07-07 | 2019-02-19 | Microstrategy Incorporated | Workstation log-in |
US10445739B1 (en) | 2014-08-14 | 2019-10-15 | Wells Fargo Bank, N.A. | Use limitations for secondary users of financial accounts |
WO2016126052A2 (en) * | 2015-02-06 | 2016-08-11 | (주)이스톰 | Authentication method and system |
US11853919B1 (en) | 2015-03-04 | 2023-12-26 | Wells Fargo Bank, N.A. | Systems and methods for peer-to-peer funds requests |
US9674200B2 (en) * | 2015-07-14 | 2017-06-06 | Mastercard International Incorporated | Identity federation and token translation module for use with a web application |
US10855664B1 (en) * | 2016-02-08 | 2020-12-01 | Microstrategy Incorporated | Proximity-based logical access |
US10231128B1 (en) | 2016-02-08 | 2019-03-12 | Microstrategy Incorporated | Proximity-based device access |
US10111095B2 (en) * | 2016-03-14 | 2018-10-23 | Verizon Patent And Licensing Inc. | Caching a pairwise master key for dropped wireless local area network (WLAN) connections to prevent re-authentication |
US11468414B1 (en) | 2016-10-03 | 2022-10-11 | Wells Fargo Bank, N.A. | Systems and methods for establishing a pull payment relationship |
US10771458B1 (en) | 2017-04-17 | 2020-09-08 | MicoStrategy Incorporated | Proximity-based user authentication |
US11140157B1 (en) | 2017-04-17 | 2021-10-05 | Microstrategy Incorporated | Proximity-based access |
US10657242B1 (en) | 2017-04-17 | 2020-05-19 | Microstrategy Incorporated | Proximity-based access |
JP6904857B2 (en) | 2017-08-31 | 2021-07-21 | キヤノン株式会社 | Delegation system, control method, and program |
US11295297B1 (en) | 2018-02-26 | 2022-04-05 | Wells Fargo Bank, N.A. | Systems and methods for pushing usable objects and third-party provisioning to a mobile wallet |
US11775955B1 (en) | 2018-05-10 | 2023-10-03 | Wells Fargo Bank, N.A. | Systems and methods for making person-to-person payments via mobile client application |
US11074577B1 (en) | 2018-05-10 | 2021-07-27 | Wells Fargo Bank, N.A. | Systems and methods for making person-to-person payments via mobile client application |
US11551190B1 (en) | 2019-06-03 | 2023-01-10 | Wells Fargo Bank, N.A. | Instant network cash transfer at point of sale |
CN112039838B (en) * | 2020-07-15 | 2022-03-15 | 中国电子科技集团公司第三十研究所 | Secondary authentication method and system suitable for different application scenes of mobile communication |
US11803626B2 (en) | 2021-06-08 | 2023-10-31 | Mewt LLC | Wireless kill switch |
Citations (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020174335A1 (en) * | 2001-03-30 | 2002-11-21 | Junbiao Zhang | IP-based AAA scheme for wireless LAN virtual operators |
US20030046541A1 (en) * | 2001-09-04 | 2003-03-06 | Martin Gerdes | Universal authentication mechanism |
US20030110375A1 (en) * | 1998-06-04 | 2003-06-12 | Z4 Technologies, Inc. | Method for monitoring software using encryption including digital signatures/certificates |
US20030112977A1 (en) * | 2001-12-18 | 2003-06-19 | Dipankar Ray | Communicating data securely within a mobile communications network |
US20030211842A1 (en) * | 2002-02-19 | 2003-11-13 | James Kempf | Securing binding update using address based keys |
US20040088544A1 (en) * | 2002-10-31 | 2004-05-06 | Tariq Muhammad Mukarram Bin | Location privacy through IP address space scrambling |
US20040250119A1 (en) * | 2003-04-30 | 2004-12-09 | Art Shelest | Authenticated domain name resolution |
US6879690B2 (en) * | 2001-02-21 | 2005-04-12 | Nokia Corporation | Method and system for delegation of security procedures to a visited domain |
US20050177733A1 (en) * | 2002-08-16 | 2005-08-11 | Togewa Holding Ag | Method and system for gsm authentication during wlan roaming |
US7069433B1 (en) * | 2001-02-20 | 2006-06-27 | At&T Corp. | Mobile host using a virtual single account client and server system for network access and management |
US20060185013A1 (en) * | 2003-06-18 | 2006-08-17 | Telefonaktiebolaget Lm Ericsson (Publ) | Method, system and apparatus to support hierarchical mobile ip services |
US20060236116A1 (en) * | 2005-04-18 | 2006-10-19 | Lucent Technologies, Inc. | Provisioning root keys |
US7171555B1 (en) * | 2003-05-29 | 2007-01-30 | Cisco Technology, Inc. | Method and apparatus for communicating credential information within a network device authentication conversation |
US7181196B2 (en) * | 2003-05-15 | 2007-02-20 | Lucent Technologies Inc. | Performing authentication in a communications system |
US7210163B2 (en) * | 2002-07-19 | 2007-04-24 | Fujitsu Limited | Method and system for user authentication and authorization of services |
US7210167B2 (en) * | 2001-01-08 | 2007-04-24 | Microsoft Corporation | Credential management |
US20070154016A1 (en) * | 2006-01-05 | 2007-07-05 | Nakhjiri Madjid F | Token-based distributed generation of security keying material |
US20070209064A1 (en) * | 2004-03-26 | 2007-09-06 | Shanghai Sanlen Info Security Co., Ltd. | Secret File Access Authorization System With Fingerprint Limitation |
US20070214498A1 (en) * | 2004-04-19 | 2007-09-13 | Global Interface | Method for Transmitting Secured Contents Over the Internet |
US20070220598A1 (en) * | 2006-03-06 | 2007-09-20 | Cisco Systems, Inc. | Proactive credential distribution |
US20070297611A1 (en) * | 2004-08-25 | 2007-12-27 | Mi-Young Yun | Method for Security Association Negotiation with Extensible Authentication Protocol in Wireless Portable Internet System |
US20080060065A1 (en) * | 2006-09-06 | 2008-03-06 | Devicescape Software, Inc. | Systems and methods for providing network credentials |
US20080065883A1 (en) * | 2006-08-24 | 2008-03-13 | Cisco Technology, Inc. | Authentication for devices located in cable networks |
US20080127317A1 (en) * | 2006-11-27 | 2008-05-29 | Futurewei Technologies, Inc. | System for using an authorization token to separate authentication and authorization services |
US20080141031A1 (en) * | 2006-12-08 | 2008-06-12 | Toshiba America Research, Inc. | Eap method for eap extension (eap-ext) |
US20080175393A1 (en) * | 2007-01-19 | 2008-07-24 | Toshiba America Research, Inc. | Kerberized handover keying |
Family Cites Families (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CA2400623C (en) | 2000-03-17 | 2007-03-20 | At&T Corp. | Web-based single-sign-on authentication mechanism |
DE60227220D1 (en) | 2001-03-29 | 2008-08-07 | Sony Corp | DEVICE FOR INFORMATION PROCESSING |
CN1329418A (en) | 2001-07-24 | 2002-01-02 | 巨龙信息技术有限责任公司 | Method for authenticating network user identity and method for overcoming user password loophole in Kerberous authentication system |
CN1243434C (en) | 2002-09-23 | 2006-02-22 | 华为技术有限公司 | Method for implementing EAP authentication in remote authentication based network |
KR20060031813A (en) | 2003-06-18 | 2006-04-13 | 텔레폰악티에볼라겟엘엠에릭슨(펍) | Method, system and apparatus to support mobile ip version 6 services in cdma systems |
US20070101132A1 (en) | 2003-06-18 | 2007-05-03 | Siemens Aktiengesellschaft | Method and device for forming an encrypted message together with method and device for encrypting an encrypted message |
CA2528787A1 (en) | 2003-06-18 | 2004-12-23 | Telefonaktiebolaget Lm Ericsson (Publ) | Method, system and apparatus to support mobile ip version 6 services |
KR100561616B1 (en) | 2003-11-26 | 2006-03-15 | 삼성전자주식회사 | Method for managing user information items in high-speed portable internet system |
CN1298194C (en) | 2004-03-22 | 2007-01-31 | 西安电子科技大学 | Radio LAN security access method based on roaming key exchange authentication protocal |
EP1657943A1 (en) | 2004-11-10 | 2006-05-17 | Alcatel | A method for ensuring secure access to a telecommunication system comprising a local network and a PLMN |
US7631347B2 (en) | 2005-04-04 | 2009-12-08 | Cisco Technology, Inc. | System and method for multi-session establishment involving disjoint authentication and authorization servers |
WO2006118342A1 (en) | 2005-04-28 | 2006-11-09 | Matsushita Electric Industrial Co., Ltd. | System, associated methods and apparatus for securing prefix-scoped binding updates |
CN100470575C (en) | 2006-04-12 | 2009-03-18 | 北京金山软件有限公司 | Method and system of saftware using license |
-
2007
- 2007-08-14 US US11/838,377 patent/US8539559B2/en active Active
- 2007-08-27 WO PCT/CN2007/070570 patent/WO2008064589A1/en active Application Filing
- 2007-08-27 EP EP07785467A patent/EP2082539A4/en not_active Withdrawn
- 2007-08-27 CN CN2007800423790A patent/CN101536438B/en active Active
- 2007-11-09 US US11/938,048 patent/US20080178274A1/en not_active Abandoned
Patent Citations (26)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030110375A1 (en) * | 1998-06-04 | 2003-06-12 | Z4 Technologies, Inc. | Method for monitoring software using encryption including digital signatures/certificates |
US7210167B2 (en) * | 2001-01-08 | 2007-04-24 | Microsoft Corporation | Credential management |
US7069433B1 (en) * | 2001-02-20 | 2006-06-27 | At&T Corp. | Mobile host using a virtual single account client and server system for network access and management |
US6879690B2 (en) * | 2001-02-21 | 2005-04-12 | Nokia Corporation | Method and system for delegation of security procedures to a visited domain |
US20020174335A1 (en) * | 2001-03-30 | 2002-11-21 | Junbiao Zhang | IP-based AAA scheme for wireless LAN virtual operators |
US20030046541A1 (en) * | 2001-09-04 | 2003-03-06 | Martin Gerdes | Universal authentication mechanism |
US20030112977A1 (en) * | 2001-12-18 | 2003-06-19 | Dipankar Ray | Communicating data securely within a mobile communications network |
US20030211842A1 (en) * | 2002-02-19 | 2003-11-13 | James Kempf | Securing binding update using address based keys |
US7210163B2 (en) * | 2002-07-19 | 2007-04-24 | Fujitsu Limited | Method and system for user authentication and authorization of services |
US20050177733A1 (en) * | 2002-08-16 | 2005-08-11 | Togewa Holding Ag | Method and system for gsm authentication during wlan roaming |
US20040088544A1 (en) * | 2002-10-31 | 2004-05-06 | Tariq Muhammad Mukarram Bin | Location privacy through IP address space scrambling |
US20040250119A1 (en) * | 2003-04-30 | 2004-12-09 | Art Shelest | Authenticated domain name resolution |
US7181196B2 (en) * | 2003-05-15 | 2007-02-20 | Lucent Technologies Inc. | Performing authentication in a communications system |
US7171555B1 (en) * | 2003-05-29 | 2007-01-30 | Cisco Technology, Inc. | Method and apparatus for communicating credential information within a network device authentication conversation |
US20060185013A1 (en) * | 2003-06-18 | 2006-08-17 | Telefonaktiebolaget Lm Ericsson (Publ) | Method, system and apparatus to support hierarchical mobile ip services |
US20070209064A1 (en) * | 2004-03-26 | 2007-09-06 | Shanghai Sanlen Info Security Co., Ltd. | Secret File Access Authorization System With Fingerprint Limitation |
US20070214498A1 (en) * | 2004-04-19 | 2007-09-13 | Global Interface | Method for Transmitting Secured Contents Over the Internet |
US20070297611A1 (en) * | 2004-08-25 | 2007-12-27 | Mi-Young Yun | Method for Security Association Negotiation with Extensible Authentication Protocol in Wireless Portable Internet System |
US20060236116A1 (en) * | 2005-04-18 | 2006-10-19 | Lucent Technologies, Inc. | Provisioning root keys |
US20070154016A1 (en) * | 2006-01-05 | 2007-07-05 | Nakhjiri Madjid F | Token-based distributed generation of security keying material |
US20070220598A1 (en) * | 2006-03-06 | 2007-09-20 | Cisco Systems, Inc. | Proactive credential distribution |
US20080065883A1 (en) * | 2006-08-24 | 2008-03-13 | Cisco Technology, Inc. | Authentication for devices located in cable networks |
US20080060065A1 (en) * | 2006-09-06 | 2008-03-06 | Devicescape Software, Inc. | Systems and methods for providing network credentials |
US20080127317A1 (en) * | 2006-11-27 | 2008-05-29 | Futurewei Technologies, Inc. | System for using an authorization token to separate authentication and authorization services |
US20080141031A1 (en) * | 2006-12-08 | 2008-06-12 | Toshiba America Research, Inc. | Eap method for eap extension (eap-ext) |
US20080175393A1 (en) * | 2007-01-19 | 2008-07-24 | Toshiba America Research, Inc. | Kerberized handover keying |
Non-Patent Citations (1)
Title |
---|
Aboba et al., IETF EAP Working Group, Internet Draft, "EAP Keying Format", Dec. 21, 2002 * |
Cited By (27)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20060078119A1 (en) * | 2004-10-11 | 2006-04-13 | Jee Jung H | Bootstrapping method and system in mobile network using diameter-based protocol |
US20080127317A1 (en) * | 2006-11-27 | 2008-05-29 | Futurewei Technologies, Inc. | System for using an authorization token to separate authentication and authorization services |
US8539559B2 (en) | 2006-11-27 | 2013-09-17 | Futurewei Technologies, Inc. | System for using an authorization token to separate authentication and authorization services |
US20080168537A1 (en) * | 2007-01-09 | 2008-07-10 | Futurewei Technologies, Inc. | Service Authorization for Distributed Authentication and Authorization Servers |
US8099597B2 (en) * | 2007-01-09 | 2012-01-17 | Futurewei Technologies, Inc. | Service authorization for distributed authentication and authorization servers |
US8005224B2 (en) * | 2007-03-14 | 2011-08-23 | Futurewei Technologies, Inc. | Token-based dynamic key distribution method for roaming environments |
US20080229107A1 (en) * | 2007-03-14 | 2008-09-18 | Futurewei Technologies, Inc. | Token-Based Dynamic Key Distribution Method for Roaming Environments |
US8285990B2 (en) | 2007-05-14 | 2012-10-09 | Future Wei Technologies, Inc. | Method and system for authentication confirmation using extensible authentication protocol |
US20090031138A1 (en) * | 2007-05-14 | 2009-01-29 | Futurewei Technologies, Inc. | Method and system for authentication confirmation using extensible authentication protocol |
US20100281523A1 (en) * | 2007-12-27 | 2010-11-04 | Yunbo Pan | Method and system for negotiating network service |
US20110107085A1 (en) * | 2009-10-30 | 2011-05-05 | Mizikovsky Semyon B | Authenticator relocation method for wimax system |
US8443431B2 (en) * | 2009-10-30 | 2013-05-14 | Alcatel Lucent | Authenticator relocation method for WiMAX system |
US20180077139A1 (en) * | 2012-05-14 | 2018-03-15 | Nec Europe Ltd. | Method and system for accessing service/data of a first network from a second network for service/data access via the second network |
US10637850B2 (en) * | 2012-05-14 | 2020-04-28 | Nec Corporation | Method and system for accessing service/data of a first network from a second network for service/data access via the second network |
WO2014168638A1 (en) * | 2013-04-12 | 2014-10-16 | Globoforce Limited | System and method for mobile single sign-on integration |
US10230715B2 (en) | 2013-04-12 | 2019-03-12 | Globoforce Limited | System and method for mobile single sign-on integration |
US9009806B2 (en) | 2013-04-12 | 2015-04-14 | Globoforce Limited | System and method for mobile single sign-on integration |
US10305900B2 (en) * | 2013-10-15 | 2019-05-28 | Telefonaktiebolaget Lm Ericsson (Publ) | Establishing a secure connection between a master device and a slave device |
US9848052B2 (en) | 2014-05-05 | 2017-12-19 | Visa International Service Association | System and method for token domain control |
WO2015171625A1 (en) * | 2014-05-05 | 2015-11-12 | Visa International Service Association | System and method for token domain control |
US11122133B2 (en) | 2014-05-05 | 2021-09-14 | Visa International Service Association | System and method for token domain control |
WO2016014079A1 (en) * | 2014-07-25 | 2016-01-28 | Hewlett-Packard Development Company, L.P. | Constraining authorization tokens via filtering |
US10129031B2 (en) * | 2014-10-31 | 2018-11-13 | Convida Wireless, Llc | End-to-end service layer authentication |
US10601594B2 (en) | 2014-10-31 | 2020-03-24 | Convida Wireless, Llc | End-to-end service layer authentication |
US10110595B2 (en) | 2015-03-16 | 2018-10-23 | Convida Wireless, Llc | End-to-end authentication at the service layer using public keying mechanisms |
US10880294B2 (en) | 2015-03-16 | 2020-12-29 | Convida Wireless, Llc | End-to-end authentication at the service layer using public keying mechanisms |
US10644875B2 (en) | 2016-04-28 | 2020-05-05 | International Business Machines Corporation | Pre-authorization of public key infrastructure |
Also Published As
Publication number | Publication date |
---|---|
CN101536438A (en) | 2009-09-16 |
US8539559B2 (en) | 2013-09-17 |
EP2082539A1 (en) | 2009-07-29 |
EP2082539A4 (en) | 2011-01-05 |
WO2008064589A1 (en) | 2008-06-05 |
CN101536438B (en) | 2012-09-05 |
US20080127317A1 (en) | 2008-05-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8539559B2 (en) | System for using an authorization token to separate authentication and authorization services | |
US11588626B2 (en) | Key distribution method and system, and apparatus | |
KR101158956B1 (en) | Method for distributing certificates in a communication system | |
KR101009330B1 (en) | Method, system and authentication centre for authenticating in end-to-end communications based on a mobile network | |
JP5166524B2 (en) | Method and apparatus for certificate processing | |
US8887246B2 (en) | Privacy preserving authorisation in pervasive environments | |
KR100704675B1 (en) | authentication method and key generating method in wireless portable internet system | |
EP1897268B1 (en) | Method for refreshing a pairwise master key | |
US7707412B2 (en) | Linked authentication protocols | |
KR101374810B1 (en) | Virtual subscriber identity module | |
US8380980B2 (en) | System and method for providing security in mobile WiMAX network system | |
US20100161958A1 (en) | Device for Realizing Security Function in Mac of Portable Internet System and Authentication Method Using the Device | |
KR20100056454A (en) | Bootstrapping method for setting up a security association | |
JP4213664B2 (en) | Non-repudiation of service agreement | |
Shon et al. | Novel approaches to enhance mobile WiMAX security | |
Rao et al. | Authenticating Mobile Users to Public Internet Commodity Services Using SIM Technology | |
Latze | Towards a secure and user friendly authentication method for public wireless networks | |
Mizikovsky et al. | CDMA 1x EV-DO security |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: FUTUREWEI TECHNOLOGIES, INC., TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NAKHJIRI, MADJID F.;REEL/FRAME:020241/0042 Effective date: 20061126 |
|
AS | Assignment |
Owner name: FUTUREWEI TECHNOLOGIES, INC., TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NAKHJIRI, MADJID F.;REEL/FRAME:021588/0168 Effective date: 20080923 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- AFTER EXAMINER'S ANSWER OR BOARD OF APPEALS DECISION |