KR100904004B1 - Authenticating users - Google Patents

Abstract

Disclosed herein is a method of authenticating a user who wants to access a service from a service provider in a communication network, the method of authenticating the user comprising: assigning a plurality of service specific identifiers to the user to access corresponding services; Providing a request from a user, the request identifying a service to be accessed and including the user's public key; And at the certification authority, authenticating the request, providing a public key certificate combining the public key in the request and a service specific identification number, and returning the public key certificate to the user.

Description

Authenticating users}

The invention relates in particular to the authentication of users in connection with providing services to users (subscribers) of a wireless communication network.

One way in which user privacy can be maintained is for a user to provide different identities to different service providers. Such identities are referred to herein as service only identities. However, in such a case, the operator of the network for subscribers needs to provide an identity management service that can associate service-specific identities with authenticated subscribers. It is also useful when an identity management provider can perform authentications on behalf of other service providers as well as on its own. This means that users can invoke personalized services without having to register individually with each service profile site.

This configuration is known as identity federation and allows service providers to read the user's identity from a centralized location. The user does not need to provide dedicated identity information to all service providers.

Currently there are two important authentication procedures defined in wireless communication networks where a user equipment (UE) in the form of a mobile terminal wishes to access a service from a service provider in the network. The so-called Liberty Alliance (LA) standard is a client that has knowledge about the identity provider that the user intends to use with the service provider or knows how to obtain knowledge about the identity provider that the user intends to use with the service provider. Use an authentication procedure that becomes a Liberty Enabled Client (LEC). This defines the service-specific identity mapping at the identity provider (IDP) side. Each subscriber has a number of identities for accessing Service Providers (SPs). The federation directory on the identity provider side stores the relationships between users, their identities and services. The identity provider asserts a service specific identity to a service provider that recognizes the user as a service dedicated identity. The ability to provide different identities to different service providers allows for subscriber privacy to be maintained. According to the Liberty Alliance standard, a user can avoid disclosing his or her actual identity when invoking services. Instead of revealing their own real identity, the user may call the services anonymously or use an alias (a service-specific identity). The federation directory maps the user's actual identity to his own aliases or service-specific identities so that the service provider does not know the actual identity. Through the pseudonym and the mapping service, the service provider can access the user's location or current state, for example. This allows the service provider to use an alias to access the user's location from the identity service provider through a mapping in the federation database. The Liberty Alliance standard specifies a registered HTTP / soap combination to be used for verification implementations. However, there are several existing services that do not know the Liberty verification implementations and rely on other forms of "assertions" for access, such as typical public key certificates. One example of such a service is access control that allows integration of virtual private networks (VPNs).

Another existing form of authentication is 3GPP support for subscriber certificates (SSCs) [3GPP TS 33.221]. It is implemented as a 3GPP generic authentication architecture (GAA) [3GPP TS 33.220] and specifies how to require subscriber certificates for dedicated identities from a certificate authority (CA). In this case, the dedicated identity is the user's identity and not service only. According to the GAA / SSC technology, a generic bootstrapping architecture (GBA) inserted at the user device side authenticates the user device with respect to an authentication server at the service provider side, and at the user device and the service provider side. The authentication server agrees on the shared key material. The generic bootstrapping architecture delivers shared key material to a Certificate Authority (CA). The user devices generate an asymmetric public / secret key pair and require authentication from the certificate authority. In the case of authentication, the certificate which associates the public key with the identity of the requesting user is returned. Such authentication procedures are protected by shared key material.

Mobile operators can authenticate their own mobile subscribers using USIM, ISIM, username / password pair or X.509 public key certificates. In the case of certificates, the authenticated identity may be in the subjectName field or may be in the SubjectAltName extension of the certificate [RFC 3280].

The 3GPP / GAA / SSC authentication procedure does not have a mechanism indicating a service provider that the subscriber wants to access. Only the user's identity can be displayed and authenticated by the certificate. There is no support for certificate-based authentication of multiple identities or service-only identities. Although the SubjectAltName extension may be used to involve multiple identities and service-specific identities, it may indicate the identity or identities intended for the user device during the authentication procedure, i.e., the service or services the user device intends to use with the certificate. There is a problem that must be present. The user device does not want to insert all possible identities in one certificate, since the certificate is public, making it very easy to find associations between different identities.

It is an object of the present invention to provide an authentication system which does not face the limitations of the two systems mentioned above.

According to one aspect of the present invention, there is provided a method for authenticating a user who wants to access a service from a service provider in a communication network, wherein the user's authentication method provides a plurality of service specific identities to access corresponding services. Assigning to a user; Providing a request from a user, the request identifying a service to be accessed and including the user's public key; And at the certificate authority side, authenticating the request and providing a public key certificate combining the public key in the request and a service-specific identity, and returning the public key certificate to the user.

In the embodiments mentioned below, the request includes a service identifier identifying a service to be accessed and a claimant identifier identifying a user. The authentication method of the user further includes mapping, at the certification authority side, the service identifier and the claimant identifier pair to a service-only identity to be authenticated. However, the request may also identify the service-only identity, and the user's authentication method may further include verifying that the user is authenticated to use the service-only identity with the certification authority. It is possible.

In a preferred embodiment, the public key is generated at the user terminal side as part of an asymmetric key pair comprising a secret key and the public key. However, key pairs may be obtained, for example, from a secure element attached to the user terminal or in other ways generated by the certification authority.

Although the present invention is particularly useful in connection with wireless communication networks, it is appreciated that the present invention is also applicable to other types of communication networks.

According to another aspect of the invention, there is provided a user terminal for use in a communication network, the user terminal comprising means for identifying a service to be accessed via the communication network and providing a request comprising a public key; Means for receiving a public key certificate provided by a certificate authority that associates the public key with a service-specific identity for a service to be accessed; And means for transmitting the public key certificate to a service provider that authenticates access to the service by authenticating a service-only identity for a user.

According to yet another aspect of the present invention, there is provided an authentication system for a communication network that allows access to a service from a service provider, wherein the authentication system for the communication network is a means for receiving a request from a user, wherein the request is Means for identifying a service to be accessed and including a user's public key; And a certification authority configured to authenticate the request and provide a public key certificate for a service-only identity of a service to be accessed and to return the public key certificate to a user.

Reference will now be made, for example, to the accompanying drawings in order to better understand the present invention and to show how the effects of the present invention can be exercised.

1 is a schematic diagram illustrating a communication network in which a subscriber can access one or more services.

2 shows an exemplary architecture for implementing one embodiment of the present invention.

3 is a diagram schematically showing a federation directory.

4 is a diagram illustrating a message flow between a subscriber and an authentication server.

5 is a diagram illustrating a message flow between a subscriber and a certification authority.

1 is a schematic block diagram illustrating a wireless communication network for providing services to a subscriber. The subscriber is presented in the form of a user equipment (UE), which may be a mobile terminal such as a mobile phone, a personal computer or other kind of mobile communication device. The user equipment UE is provided with a reception / transmission circuit 50 capable of receiving and transmitting data such as request and response messages to the network via a radio link RL capable of supporting wireless communication. . The user equipment UE also includes a memory 52 that holds authentication information, as will be discussed in more detail below. The mobile terminal will be described in more detail below, but it is possible to execute client software. The user equipment UE representing the subscriber communicates with a number of other service providers SP1, SP2, ... SPN via an operator network. The network may include an authentication subsystem 26 or access an authentication subsystem 26, where the authentication subsystem 26 is a centralized identity provider for service providers who are accessing the network. It serves as. Subscribers who wish to access a service are authenticated based on their own authenticated identity.

2 illustrates an exemplary architecture for implementing one embodiment of the present invention. FIG. 2 illustrates a generic authentication architecture including a Generic Bootstrapping Architecture (GBA) client 4 running on a mobile terminal connected to an authentication server (Bootstrapping Server Function (BSF)) via a Ub interface. (Generic Authentication Architecture; GAA) The authentication server 6 is connected to a Home Subscriber Server (HSS) / Home Location Register (HLR) 8, which is the home subscriber. The server (HSS) / home location register (HLR) 8 stores authentication data including International Mobile Subscriber Identity (IMSI) and keys K for subscribers. Is connected to a Certificate Authority (CA) 10 via a Zn interface, which includes a federation directory (FD). The federation directory FD is illustrated in Figure 3. The federation directory FD is a plurality of service-specific identities that a subscriber uses as his face to access other services from service providers. Associate each subscriber identity with a subscriber identity in the federation directory, a user name by which the operator network recognizes the subscriber, reference number 12 denotes a public key certificate; Certificate (PKC) domain The public key certificate domain 12 executes on a mobile terminal connected to the authentication client 4 via a PK interface and connected to the certificate authority 10 via a Ua interface. Certificate client 14). The public key certificate domain 12 also includes a Security (Transport Layer Security) SEC (TLS) gateway function 16 connected to the certificate client 14 via a PK1 interface. do. The secure (transport layer security) (SEC (TLS)) gateway 16 is part of an HTTP server and performs the transport layer security (TLS) authentication portion instead of the HTTP server.

In the following description, note that http-based services are implemented in the given example. However, basic principles may also be used for Internet Protocol Security (IPSec), Virtual Private Networks (VPN), or Wireless Local Area Networks (WLAN).

Reference numeral 18 represents an http domain, which includes, for example, an http client 20 in the form of a browser, which http client 20 provides the public key certificate (PKC) domain via an HT3 interface. It is connected to the certificate client 14 of and connected to the authentication client of the GAA domain through the TE-AA interface. The http client 20 is connected to the http classifier 22 via the HT1 interface. The http classifier is connected to the http server function 24 via the HT4 interface. The http classifier 22 is connected to a certificate client of the public key certificate (PKC) domain via an HT2 interface. The http server function 24 is connected to a secure (transport layer security) (SEC (TLS)) gateway function 16 of the public key (PKC) domain via an internal SP-AA interface. The http client and classifier are run in a mobile terminal (UE). The http server function 24 is associated with one of the service providers (SPs) of FIG.

Referring back to the GAA domain 2, the GBA authentication client 4 at the user equipment UE authenticates to the BSF server, and the GBA authentication client 4 at the user equipment UE and the The BSF Server agrees on the shared key material. The BSF server 6 is used to authenticate the user device using HTTP Digest Authentication and Key Agreement (AKA) protocols as defined in the Request for Comments (RFC) 3310, whereby This results in shared key material between the BSF server 6 and the user equipment UE. The BSF server 6 interfaces with the home subscriber server / home location register 8 to withdraw corresponding authentication information in the form of authentication triplets / vectors. The certification authority 10 may serve as a PKI portal and provide a certificate for the user device to deliver an operator CA certificate. In both cases, the requests and responses are protected by a shared key material preset between the user equipment and the authentication server.

A method according to an embodiment of the present invention will now be described that allows a subscriber using a user equipment (UE) to access a service provided by one of the service providers (SPs). The GBA client 4 communicates with the authentication server BSF to authenticate the subscriber based on his own subscriber identity (e.g. username) and agree on the shared key material Ks. The shared key material is obtained from authentication information of both the certificate authority 10 and the authentication client 4. The client 4 obtains the shared key material Ks through the HTTP Digest AKA protocol, which requires a secret key and cryptographic function, and extracts the shared key material Ks from the authentication challenge. The shared key material is held in the federation directory FD with respect to the associated subscriber identity during this authentication session. The shared key material takes the form of an encryption code.

At this time, the user equipment UE generates a public key / secret key pair and stores them together with a service identifier SI _i , which identifies a service that the subscriber wishes to access. The public key / secret key pair may be stored in the memory 52 of the user device or in a smart card accessible to the user device.

The certificate client 14 is called to request a certificate. The request includes the service identifier and the public key but the secret key keeps secret. The request for the certificate is protected with the shared key material and sent to a Certificate Authority (CA) via the Ua interface. The subscriber identity is also sent with the request.

On the certificate authority 10 side, the federation directory FD maps the service identifier SI _i to a service dedicated identity S _i for such a service and such a user name.

The certification authority 10 fetches the shared key material K _si based on the user name from the BSF server 6 and verifies the authentication header of the request. This is mentioned in TS 33.221. Assuming that the request is valid, the certificate authority 10 provides a certificate that associates a public key with a service-specific identity for the service identified by the service identifier in the request. The certificate is returned to a user device (UE) representing a subscriber via the Ua interface, and the user device (UE) stores the certificate in the memory 52 or a smart card. In the case of many devices, the user equipment (UE) may transfer the certificate to another device (laptop), perhaps using the secret key, unless another device generates the secret key itself.

The certificate client 14 informs the http client 20 via the HT3 interface that a valid certificate has been received and sends the certificate for authentication to the SEC (TLS) gateway function 16 via the PK1 interface. At this time, the http client 20 calls the http server function unit 24 of the service provider for the service that it wants to access, and includes the certificate. The http client 20 also includes evidence that the service provider can validate the certificate, including, for example, a digital signature that includes data encrypted with the secret key.

The SEC (TLS) gateway 16 validates the certificate via a PK3 interface to a list of certificate authorities, and once the certificate is authenticated, the service can be called for a subscriber. The SEC (TLS) gateway function 16 also challenges the client and verifies the response to authenticate the client PK1, and the http server function 24 authenticates the requested service to the clients HT4. To provide).

Authentication via the Ub interface is made according to 3GGP standards TS 33.220, where authentication can also be performed using 2G SIM if authentication is performed based on HTTP Digest AKA [RFC 3310].

Figure 4 shows part of the message flows between the authentication server 6 (BSF) and the user device (UE) implementing the authentication client 4 (UE) during the bootstrapping procedure. The GBA client 4 initiates the authentication procedure by providing an authentication request 30 (GET request). The authentication request uses the subscriber identity to identify the user, but in this example, the subscriber identity is an IP Multimedia Private Identity (IMPI). Another variant may be IMSI or the user equipment UE may generate a pseudo IMPI from the IMSI (as defined in TS 23.003). The HTTP response 32 is returned by acknowledging the user identity IMPI and returning a nonce containing the RAND and AUTN of the AKA that uniquely identifies the request. The authentication client 4 on the user equipment side returns an HTTP request 34 via a suitable password obtained from AKA, and the authentication server (BSF) 6 is used as a user name in the Ua interface (see FIG. 4). Respond by returning authentication information including a bootstrapping transaction identifier (B-TID) (not shown), and the shared key material is obtained from the authentication information. It is clear here that although the BSF accesses authentication information from the HSS, this interaction is not shown because such is already known.

After the shared key material is agreed by the message exchange of Fig. 4, the certificate client on the user equipment side generates a certificate request (PKCS # 10) which is sent to the CA via the Ua interface. This is shown in FIG. The certificate request includes a number of fields according to a standard set as follows.

POST / certificaterequest / HTTP / 1.1

Authorization: Digest

     username = "adf..adf",

     realm = "ca-naf@operator.com",

     qop = "auth-int",

     algorithm = "MD5",

     uri = "/ certificaterequest /",

     nonce = "dffef12..2ff7",

     nc = 00000001,

     cnonce = "0a4fee..dd2f",

     response = "6629..af3e",

     opaque = "e23f45..dff2"

<base64 encoded PKCS # 10 request>

The fields are known from RFC 2617. In this example, the HTTP message includes an authentication HTTP header where "username" may be a B-TID and the "opaque" field may contain service identifiers.

The "Authorization" is an HTTP header associated with HTTP Digest Authentication [RFC 2617]. Parameters of the authentication header are used to authenticate the request to protect the request integrity. The PKCS # 10 request includes a certificate request itself that includes a service identifier and a user's public key.

According to one embodiment of the invention, the certificate request (PKCS # 10) also includes a service identifier field that identifies the service to be accessed by the user. The service can be identified in any of a number of ways, for example by a transparent string, a realm address, a Universal Resource Identifier (URI), a distinguished name, and the like. What is needed is a unique identifier for the particular service to be accessed by the user. The service identifier is included in the PKCS # 10 request as one of the extensions. As an example, there is a "extension Request" attribute in PKCS # 9 that can be used with PKCS # 10, using subjectAltName as the requested extension.

Alternatively, in Certificate Request Message Format (CRMF) [RFC 2511], such may be the sujectAltName extension of the Certificate Template field.

The CA (NAF) derives the shared key material from the authentication server BSF based on the user name (B-TID) provided in the authentication request (PKCS # 10) and verifies the authentication header using the shared key material. If such verification is successful, the CA (NAF) processes the authentication request and returns a certificate response referred to as CERT in FIG. The certificate response has the following format.

HTTP / 1.1 200 OK

Content Type: application / x509-user-cert

Authentication-info: nextnonce = "4ff232dd ... dd"

      qop = auth-int

      rspauth = "4dd34 ... 55d2"

      cnonce = "0a4fee ... dd2f"

      nc = 00000001

<base 64 encoded subscriber x509 certificate>

The user device stores the certificate in a memory or a smart card on the user device side. The certificate activates the public key along with the service identifier and can be authenticated using an asymmetric public / secret key pair.

By adding the service identifier to the authentication request, this allows subscribers to have multiple certificates for multiple services. However, a user may have a single identity for each service, because each subscriber certificate may have a specific, rather than common ("global") identity, in which its activities can be tracked and subscriber privacy may be compromised. This is because it is associated with a service-only subscriber identity. In other words, we replaced subscriber and service dedicated Liberty Alliance verification implementations with subscriber and service dedicated public key certificates. In the above-mentioned embodiment, the CA identifies a service dedicated user identity based on the mapping and shared key material held in the federation database.

In a variant embodiment, the user equipment (UE) may send an authentication request indicating its preferred identity, for example if the subscriber has several names for accessing the service provider.

On the CA (or inherent federation directory) side, the (claimer identifier, service identifier) pair is mapped to a service-only subscriber identity held in the federation database. The certificate authority registers the public key certificate with respect to the mapped identity and returns it to the user device.

This allows subscribers to have multiple identities in multiple certificates. The public keys of the certificates must be different from disabling the identities. Thus, the embodiments of the present invention mentioned above support Liberty Alliance (LA) privacy standards with identity mapping via public key certificate technology, but can be applied to a wider range of applications than the LA verification implementation mechanism.

In the above-mentioned embodiment, the service identifier is included in an additional extension field of the PKCS # 10 message. The service identifier is mapped to a service-only identity on the side of the federation database (FD) associated with the certification authority (CA).

According to a first variant embodiment, it is possible to send a service-only identity in a request for authentication. In other words, the UE itself maps the subscriber identity to the desired service-only identity for the certificate. In such cases, the certification body shall verify that the subscriber actually owns the required identity and maintain an identity database for such verification. Therefore, the resulting architecture is more complex than the above-mentioned embodiment, but the standard PKCS # 10 protocol can be employed without adding anything between the user equipment and the network.

An additional variant allows a particular type of name string to be displayed in the subject field of the PKS # 10 message. For example, in the case of a user @ area name, the area portion may be a service identifier. In the case of a differentiated name, the organization part may be a service identifier. For example, the difference name “CN = username, O = realm” can be used as mentioned in RFC 3280.

As mentioned above, the present invention may be implemented in an architecture other than the http server architecture mentioned above. In particular, the functions of the SEC (TLS) gateway and http server and associated interfaces (PK1, PK3, HT4, SP-AA) receive a subscriber certificate for authentication, and optionally validate the certificate (PK3). ), It may be replaced by a single function that challenges the client, verifies the response to authenticate the client (PK1), and provides the requested services to the authenticated clients (HT4).

Claims (29)

delete A method of authenticating a user who wants to access a service from a service provider in a communication network, the method comprising: The authentication method of the user, Assigning a plurality of service-specific identities to a user for accessing corresponding services; Providing a request from a user device, the method comprising: providing a request including a public key of the user and identifying a service to which the request is to be accessed; And At the certification authority, authenticating the request and providing a public key certificate combining the public key in the request with a service-specific identity, and returning the public key certificate to the user device, The request includes a service identifier identifying a service to be accessed and a claimant identifier identifying a user, The authentication method of the user, At the certification authority, mapping the service identifier and the claimant identifier to a service-only identity to be authenticated. A method of authenticating a user who wants to access a service from a service provider in a communication network, the method comprising: The authentication method of the user, Assigning a plurality of service-specific identities to a user for accessing corresponding services; Providing a request from a user device, the method comprising: providing a request including a public key of the user, the service identifying the service to be accessed; And At the certification authority, authenticating the request and providing a public key certificate combining the public key in the request with a service-specific identity, and returning the public key certificate to the user device, The request identifies the service dedicated identity, The authentication method of the user, Verifying that the user has been authenticated to use the service-only identity through the certification authority. delete delete delete delete delete delete delete delete delete delete delete delete An authentication system for a communication network that allows access to services from a service provider, The authentication system for communication network, Means for receiving a request from a user, the request identifying a service to be accessed and including a user's public key; And A certification authority configured to authenticate the request and provide a public key certificate for a service-only identity of a service to be accessed and to return the public key certificate to a user, The authentication system for communication network, And a federation database configured to map service and requestor identifiers to service dedicated identities to access corresponding services. delete delete delete delete delete delete delete delete delete delete delete delete delete

Images