KR20150069001A - Restricted certificate enrollment for unknown devices in hotspot networks - Google Patents

Abstract

A network access system, for example, a network hotspot 110, may be used to allow a mobile network access device 180, e.g., a smartphone or WiFi-only device, to specify network access standards and / Or device identification data. The network access standard specification may be provided by the mobile network access device 180 to the online signing server 130, OSU, via the EKU key purpose field of the PKCS10 certificate signing request. The device identification data may be provided to the OSU 130 via the subject field of the signature request. The OSU 130 may require that the device identification data and the device identification data provided by the mobile network access device 180 be the same before the mobile network access device 180 requests the signed network access certificate.

Description

[0001] RESTRICTED CERTIFICATE ENROLLMENT FOR UNKNOWN DEVICES IN HOTSPOT NETWORKS [0002]

This application claims priority to a previously filed U.S. Provisional Patent Application No. 61 / 726,009, filed November 13, 2012, entitled " Restricted Certificate Enrollment for Unknown Devices in Hotspot Networks & A patent application is incorporated herein by reference in its entirety.

This disclosure generally relates to the field of networked wireless communications.

This section introduces aspects that may be helpful in facilitating a better understanding of the present invention. Accordingly, the statements of this section should be read in this light and should not be construed as an admission that such statements are prior art or non-conventional.

Recent advances in mobile devices and mobile applications have resulted in significant bandwidth and performance requirements for mobile networks. Mobile and WiFi network technologies and standards are evolving toward a heterogeneous network (HetNet) architecture. This evolution is expected to allow mobile service providers to pass mobile network traffic over WiFi networks and also enable mobile service providers to provide comprehensive service plans including cellular and WiFi access.

One embodiment provides a method of operating an online signup server (OSU), for example. The server receives a network access certificate signing request from a client device, for example, a mobile network access device or a WiFi-only device. The server forwards the certificate request to the certificate issuing authority, provided that the certificate signing request includes the same network access standard as the predetermined value.

Another embodiment provides a server, e.g., an OSU server, configured to perform embodiments of the above-described method. The server includes a processor, and a network interface coupled to the network. The program code is encoded on the non-transitory machine-readable storage medium. The program code is executed by a processor to implement a method comprising receiving a certificate enrollment request from a mobile network access device via a network interface. The method further includes forwarding the certificate enrollment request to the certificate issuing authority via the network interface, provided that the certificate enrollment request includes a network access standard identifier equal to a predetermined value.

In some embodiments, the above-described method includes receiving a certificate signing request from a mobile network access device or a WiFi-only device, and sending a certificate signing request, on condition that a message containing device identification data has previously been received from the device And forwarding to the certificate issuing authority. In some embodiments, the predetermined value specifies a hotspot 2.0 (HS2.0) or later standard. In certain embodiments, the predetermined value may be conveyed via an extended key usage (EKU) key purpose field. In some embodiments, the predetermined value includes the string id-kp-HS2.0Auth. In various embodiments, the client device may include, for example, a mobile phone, a smartphone, a mobile computing device, a mobile computing device without mobile phone capability, or a personal computer with a WiFi.

Another aspect provides a method of operating a certificate approval server, e.g., a certificate authority (CA), for example. The method includes receiving, by a certificate acceptance server, a certificate signing request for network access, for example, from a mobile network access device. The server provides the device with a signed network access certificate, provided that the certificate enrollment request includes the same network access standard as the predetermined value.

Another embodiment provides a server configured to perform embodiments of the method described above. The server includes a processor, and a network interface operatively coupled to the network. The program code is encoded on the non-transitory machine-readable storage medium. The program code is executed by a processor to implement a method comprising receiving a certificate enrollment request from a mobile network access device or a WiFi-only device via a network interface. The signed network access certificate is provided to the device via the network interface, provided that the certificate enrollment request includes the same network access standard as the predetermined value.

In various embodiments, the signed access certificate includes device identification data that identifies the mobile network access device. In some such embodiments, the device identification data is carried in the subject field of the signed certificate. In some embodiments, the network access standard specification specifies HS2.0 or later standards. In some embodiments, the network access standard specification is conveyed in the EKU_key_purpose field of the signed certificate. In some embodiments, the signed access certificate includes specifying that the network access standard specification is dangerous. In some embodiments, the device identification data includes an IMEI, a MEID, a MAC address or a unique device identification (ID), e.g., a serial number.

Another aspect provides a method for operating, e.g., a mobile network access device, e.g., a mobile phone or WiFi-specific device. The mobile device receives a certificate for access to the service provider network. The device sends a certificate signing request to the service provider network server, and the signature request includes a network access standard specification. The mobile device receives a signed access certificate that includes a network access standard specification.

Another embodiment provides a mobile network access device, e.g., a mobile phone or WiFi-only device, configured to perform embodiments of the above-described method. The mobile network access device includes a processor, and a transceiver configured to communicate with the wireless network. The program code is encoded on the non-transitory machine-readable storage medium. The program code is executed by a processor to implement a method comprising receiving a certificate for access to a service provider network via a transceiver. The certificate signing request is sent to the service provider network server via the transceiver, and the signature request includes a network access standard specification. The signed access certificate is received via the transceiver, and the certificate includes a network access standard specification.

Various embodiments of the method further comprise providing device identification data to a network access server by a mobile network access device or a WiFi dedicated device, wherein the signed access certificate includes device identification data. In some such embodiments, the device identification data is carried in the subject field of the signed certificate. In some embodiments, the network access standard specification specifies HS2.0 or later standards. In some embodiments, the network access standard specification is conveyed in the EKU_key_purpose field of the signed certificate. In various embodiments, the client device may comprise a mobile phone, a smart phone, a mobile computing device, a mobile computing device without mobile phone capability, or a personal computer with a WiFi. In some embodiments, the signed access certificate includes specifying that the network access standard specification is dangerous.

Another embodiment provides a method of operating an authentication, authorization and accounting (AAA) server, for example. The method includes receiving a network access request by the server from a client device, the access request including an access certificate. The server determines the destination assignment associated with the certificate, e.g., the key purpose. If the destination specification matches a predetermined destination specification, e.g., for a particular network access standard, the server grants access to network services by the client device.

Another embodiment provides a server configured to perform embodiments of the method described above. The server includes a processor, and a network interface operatively coupled to the network. The program code is encoded on the non-transitory machine-readable storage medium. The program code is executed by a processor to implement a method comprising receiving a network access request including a certificate from a client device via a network interface. The network server determines the purpose associated with the certificate. Access to network services by the client device is granted, provided the purpose is a predetermined purpose.

In various embodiments, the predetermined purpose includes access to the hotspot network. In some such embodiments, the hotspot network conforms to HS 2.0 or later network standards. In various embodiments, the method further comprises refusing network access to the client device, on condition that the certificate authority determines that the certificate provided by the client device has been revoked. In various embodiments, the certificate includes an object in an Extended Key Usage (EKU) Key Purpose field. In various embodiments, the server is an Authentication, Authorization, and Accounting (AAA) server.

A more complete understanding of the present invention may be obtained by reference to the following detailed description, taken in conjunction with the accompanying drawings.
Figure 1 illustrates a service provider architecture including a system, e.g., a service provider network and a network access hotspot, wherein the network access hotspot comprises OSUs, AAAs and CAs configured in accordance with various embodiments disclosed herein, And a mobile network access device, e.g., a mobile phone, configured to obtain access to network services via a hotspot in accordance with various embodiments disclosed herein.
Figure 2 illustrates an exemplary embodiment of a mobile network access device, e.g., the access device of Figure 1, configured to operate in accordance with various embodiments.
Figure 3 illustrates an exemplary embodiment of a network server configured to operate in accordance with various embodiments, e.g., OSU, AAA, or CA servers of Figure 1.
Figures 4 and 5 illustrate an embodiment of a method of illustrating the communication of messages, e.g., between a client, e.g., an access device of Figure 1, with an OSU server, an AAA server, and a CA server, in accordance with various embodiments. Give examples.
Figure 6 schematically illustrates PKCS message fields configured in various embodiments, e.g., as used in some embodiments of the methods of Figures 4 and 5, for example.
Figure 7 schematically illustrates a network access certificate, where the certificate fields are configured as described for various embodiments, including the methods of Figures 4 and 5.

The present disclosure is directed to methods and systems for online certificate registration by unknown and / or unregistered mobile network access devices that request network access, for example, through a mobile hotspot service provider. One such hotspot service provider type follows the hotspot 2.0 standard referred to herein, sometimes briefly as HS2.0, and / or subsequent modifications.

Continued development of specifications for the improved "next generation" mobile hotspot network architecture maintains active efforts. HS2.0 is considered a key enabling technology for the convergence of 4G mobile LTE networks and WiFi networks to the next generation heterogeneous network ("HetNet") architecture. The various embodiments described herein refer to HS2.0, but the scope of the present disclosure and claims is not limited to HS2.0, for example, current or prior standards for similar purposes, HS2.0 standard , Or other or later developed standards that use similar protocols.

HS2.0 allows mobile devices such as mobile network access devices, e.g., smartphones or tablet computers or other mobile computers, to dynamically search for available and appropriate HS 2.0 networks from a list of prioritized networks , Register for the service, and remotely configured to have the access qualifications needed to access the HS 2.0 network. To make HS2.0 network access secure and seamlessly accessible while on the move, devices may be provided with an X.509 certificate for authentication during initial WiFi access.

Devices registering for HS2.0 access are typically a priori unknown (e.g., unregistered) to the HS2.0 network operator. Thus, such devices may need to register for access to the network online, for example, when facing a network access point. The need for on-line registration of these unregistered devices for X.509 authentication certificates creates security problems for HS2.0 service providers. Since the devices are not known to the HS2.0 operator, a certificate issuing authority (CA) within or connected to the HS2.0 operator network can not typically authenticate the association of the requested certificate authority with the device that registers the certificate. This may result in a mechanism by which a malicious device may impersonate as a requesting entity for certificate enrollment, thereby allowing the entity to receive a certificate from the CA that has the unauthorized privilege.

In the case of known / pre-registered or pre-provisioned devices, and in the case of off-line registration by administrator verification, mechanisms for providing protection devices are known. However, these methods are generally not applicable in the case of online certificate enrollment of unregistered devices applicable for HS2.0 WiFi access use cases. Therefore, there are a need for methods and devices for preventing misuse of on-line certificate registration of unregistered devices under these circumstances.

The embodiments described herein provide methods and / or devices configured to overcome the aforementioned drawbacks of conventional certificate issuance. As described more fully below, some embodiments provide authentication of an unknown device in a wireless network by providing values for the keyPurposeID field provided by RFC 5280 published by the Internet Engineering Task Force (IETF) This value identifies the authorized connection by the registration device. Some embodiments may also be used in the case where the registration device has an identifier unique to the online signing server (OSU), e.g., an International Mobile Equipment Identity (IMEI) number, a WiFi Medium Access Control (MAC) address, Lt; RTI ID = 0.0 > ID < / RTI > In such embodiments, the OSU may require that the identity provided in a subsequent certificate signing request (CSR) match the identity provided during registration, thereby preventing another device from pretending as a registered device.

First, referring to FIG. 1, a system 100 is illustrated, such as a communications network configured to provide wireless connectivity, for example, in accordance with the HS 2.0 standard and various embodiments described herein. System 100 may be referred to herein as network 100 as a synonym without limitation. As previously described, embodiments of the system 100 are not limited to the HS2.0 standard. The system 100 includes a network 105, e.g., a service provider network (SPN) and a hotspot 110, e.g., a Wi-Fi access network (WAN). The network 105 includes an authentication, authorization and accounting (AAA) server 115, a policy server 120, a subscription calibration server 125 and an on-line signatures (OSU) The OSU server 130 is connected to the CA server 135. Servers 115, 120, 125 and 130 are connected to the service provider core service provider (SP) network 140 via an unreferenced data path and then the SP network 140 is connected to the Internet 145 .

In various embodiments, the OSU 130 complies with the HS 2.0 standard for operation as an on-line signing server. Thus, the OSU 130 provides registration services to wireless devices for registering for access to the network 100. Embodiments of the present invention provide, inter alia, systems for protecting the process of online certificate registration for HS 2.0 access.

The hotspot 110 includes an HTTP server 150 and an AAA server 155. Servers 150 and 155 are each connected to a radio access network, where an access control list (ACL) is applied at first router 160. The first router 160 is connected to a second router 165 and the second router 165 is then connected to a radio frequency (RF) transceiver 170, for example, from a radio access node. The hotspot 110 is connected to the network 105 via an unreferenced data path between the SP network 140 and the first router 160. The user 175 may obtain access to the Internet 145 through the mobile network access device 180, which is referred to herein and in the claims as the client device 180 at times. The term "client device" includes devices sometimes referred to as "user equipment" or UE by those skilled in the relevant art, such as mobile phone handsets. The client device 180 may provide wireless data connection to the hotspot 110 via a smart phone, personal digital assistant (PDA), netbook, notebook or tablet computer, laptop computer, or RF transceiver 170 ≪ / RTI > and / or may be a similar device that is configured to negotiate and maintain. In various embodiments, the client device 180 is capable of communicating with the WiFi network and, in some embodiments, also with the cellular network. In some cases, the client device 180 is, for example, "WiFi dedicated" without the ability to communicate with the cellular communication network. As used herein, a "mobile" device is a device that is typically configured to be moved by a human without mechanical assistance. In this context, mechanical assistance excludes personal organizational devices such as backpacks, backpacks, briefcases, and the like.

2 illustrates an apparatus 200, e.g., a client device 180, that is configured to operate in accordance with various embodiments. Those skilled in the art will recognize that the following description of device 200 is representative of many possible implementations. In addition, while the various functions of the device 200 may be described with discrete functional blocks for convenience, those skilled in the art will recognize that these functions may be distributed among the various components within the device 200, Or may be implemented by other components.

In an exemplary embodiment, the apparatus 200 includes a transceiver 210, a processor 220, and a memory 230. Transceiver 210 is coupled to antenna 240 and is operative to receive and / or transmit RF signals via antenna 240. The processor 220 operates in cooperation with the transceiver 210 and the memory 230 to modulate and encode the transmitted RF signals and / or to demodulate and decode the received RF signals. Transceiver 210, processor 220 and memory 230 may be conventional, with the exception of embodiments within the scope of this disclosure. The memory 230 may be a tangible non-volatile storage medium, e.g., RAM, ROM, flash memory, and the like. The memory 230 includes the steps, e.g., instructions, configured to implement the various embodiments described below, for example, methods 400 and 500 described below.

FIG. 3 illustrates an apparatus 300 representing, for example, an AAA server 115, an OSU server 130, and a CA server 135 configured to operate in accordance with various embodiments. Those skilled in the art will recognize that the following description of device 300 also represents many possible implementations. In addition, while the various functions of the device 300 may be described as discrete functional blocks for convenience, those skilled in the art will recognize that these functions may be distributed among the various components within the device 300, Or may be implemented by other components.

In the illustrated embodiment, the device 300 includes a network interface 310, a processor 320, and a memory 330. The network interface 310 operates to receive and / or transmit data over the network 340, e.g., a local area network or the Internet. Processor 320 operates in cooperation with network interface 310 and memory 330 to format data and / or receive data from the network for transmission to the network. Network interface 310, processor 320 and memory 330 may be conventional, with the exception of embodiments within the scope of this disclosure. Memory 330 may be any type of non-volatile storage medium, e.g., RAM, ROM, flash memory, magnetic disk, optical disk, The memory 330 includes the steps, e.g., instructions, configured to implement the various embodiments described below, for example, methods 400 and 500, described below.

4 illustrates a method 400 for authenticating a client device 180, for example, to receive network services from a network 105. As shown in FIG. Some aspects of method 400 may be implemented in a variety of standards, such as public key cryptographic standard (PKCS) developed and / or distributed by RSA Security, Inc or IETF of MA Bedford, USA, for example, by RFC 5280 , Which is hereby incorporated by reference in its entirety. The method 400 describes the interaction between the client 410, the OSU server 130, the AAA server 115, and the CA server 135. The client 410 represents various embodiments of the client device 180, e.g., a smartphone, PDA, netbook, notebook or tablet computer or laptop computer. The various steps of the method 400 may be performed by any of a number of examples of device 200 (e.g., client device 180) and multiple instances of device 300 (e.g., OSU server 130) , AAA server 115 and CA server 135).

At 430, the client 410 sends an HTTPS or HTTP GET request for a uniform resource identifier (URI) from a list element associated with the hotspot 110 provider, for example, to the OSU server 130, A certificate request is issued. At step 435, the OSU server 130 forwards the certificate request to the CA server 135. The CA server 135 returns the requested certificate to the OSU server 130 in step 440. [ Such a certificate may be referred to herein as a certificate authority certificate or more simply a CA certificate, and may sometimes be referred to as a root certificate.

At step 445, the OSU server 130 returns the CA certificate to the client 410. The CA certificate may be, for example, an X.509 certificate. In one embodiment, the OSU server 130 provides a CA certificate with a "revocation" -certificate-private PKCS7 message in the "application / pkcs7-mime" format. The client 410 in step 450 then includes a predetermined parameter value specifying a network access standard, illustratively, a hotspot access standard such as HS2.0 (but not limited to such a standard) To the OSU server (130). Standards can be passed through the EKU_key_purpose field of the PKCS10 message. Such a value may be referred to as "HS2.0" without limitation in the following discussion. In this context, the hotspot access standard is a standard that specifies protocols for configuration and / or maintenance of communications between the mobile device and the WiFi network architecture. In various embodiments, the messages sent by the OSU server 130 comply with the PKCS10 standard. Without limitation, the value of the EKU_key_purpose field may be set to "id-kp-HS2.0Auth".

6 schematically illustrates a portion of a PKCS message 600, e.g., a PKCS10 message. Message 600 includes some parameter fields. The destination parameter field 610 provides a value for future use by the CA 135 to provide a client certificate. The EKU_key_purpose parameter field 620 provided by the IETF RFC 5280 standard provides a mechanism to specify that the network access request by the client 410 is intended to be performed within the applicable hotspot standard, for example, HS2.0 . Of course, the field 620 may include any appropriate value that conveys the standard with which the communication between the client device 180 and the network 105 will be performed.

Next, returning to Fig. 4, at step 455, the OSU server 130 sends a request to the CA server 135 to register the client certificate. The request includes the value of the target parameter field 610 received by the OSU server 130, e.g., EKU_key_purpose = HS2.0.

At step 460, the CA server 135 returns the registered certificate to the OSU server 130. The registered certificate may be referred to herein as a client certificate.

FIG. 7 schematically illustrates a client certificate 700 configured in accordance with various embodiments. The client certificate 700 includes an object parameter 705 and an EKU list 710. The EKU list 710 includes various additional parameters including a keyPurposeID parameter 720 and a risk parameter 730, each of which is further described below.

The client certificate 700 includes the previously provided value in the keyPurposeID parameter 720 via the parameter field 620 of the PKCS message 600 (FIG. 6). keyPurposeID parameter 720 may have the same value as that specified in step 450, e.g., id-kp-H2.0Auth. Optionally, the client certificate 700 includes a "DANGER" designation. This designation is schematically illustrated in that the risk parameter 730 of the client certificate 700 is set to the value "RISK ". The "DANGER" designation may be used to indicate that the processing of the associated EKU list 710 is mandatory by the certificate processing entity, for example OSU 130.

Returning to Fig. 4, at step 465, the OSU server 130 provides the client 410 with a client certificate. At step 470, the client 410 attempts to access the hotspot network by presenting the client certificate to the AAA server 115. The client 410 may use, for example, the extensible authentication protocol-transport layer security (EAP-TLS) protocol to establish network access.

At optional step 475, the AAA server 115 sends a message to the CA server 135 to determine whether the client certificate has been revoked. If the client certificate has not been revoked, at step 480, the CA server 135 responds to indicate that the certificate has not been revoked. At step 485, the AAA server 115 may perform additional checks on the client certificate. For example, the AAA server 115 may verify that the specified purpose of the signed certificate, for example, id-kp-H2.0Auth, is a predefined permitted purpose. Although step 485 is shown as occurring after completion of steps 475/480, embodiments are not limited to this order of steps.

At step 485, the AAA server 115 may perform one or more of the following operations. First, the AAA server 115 can authenticate the client certificate by verifying the integrity of the certificate. This can be done, for example, by first generating a one-way hash of the certificate content. In some embodiments, this may be done using a hash algorithm indicated in the client certificate. In these cases, the hash value may be temporarily stored, for example, in memory. Next, the digital signature embedded in the client certificate can be decrypted using the public key included in the certificate. In other embodiments in which the CA server 135 issues a client certificate, the public key may be used from the CA root certificate. If the hash values match, the AAA server 115 may conclude that the client certificate has not changed since it was created. AAA server 115 may also check the Online Certificate Status Protocol (OCSP) to determine if the client certificate is still valid. AAA server 115 may also determine, at step 485, that the EKU_key_purpose field, e. G. KeyPurposeID parameter 720, is properly reported. As previously described, the content of the keyPurposeID parameter 720 may determine an authorized access to the client device 180. [ Thus, in order to continue without limitation the previous example, if this value is "id-kp-HS2.0Auth ", client device 180 may be authorized to access the Internet 145, For example, privileges for email and / or VPN (but not limited to) may not be approved.

Finally, at step 490, if the client certificate and the specified purpose are valid, the AAA server 115 delivers a message to the client 410 indicating that network access is granted. This message can be passed back through the EAP-TLS protocol.

5 illustrates an embodiment of a method 500 that includes additional aspects for granting access to a network 105 by, for example, a client 410 (e.g., a client device 180). In this embodiment, the subject field of a certificate, e.g., an X.509 certificate, is identified by identifying data identifying the client device 180, e.g., an IMEI number, a MEID number, a WiFi MAC address, . With the exception of the following steps, the steps of method 500 may be as described for method 400.

At step 510, the client 410 provides identification data, e.g., "deviceID" or "DeviceInfo", to the OSU server 130 via a message. The message may be delivered, for example, by the HTTPS protocol. The OSU 130 can record the identification data in the database. The client device 180 may include the identification parameter as the subject name in the certificate request sent to the OSU 130 in step 450 and the CA server 135 may send the client certificate provided in step 460 And will include the subject name. In an alternative embodiment, the client device 180 may provide an identification parameter via the SubjectAltName field of the certificate signing request. In another alternative embodiment, the OSU 130 may obtain identification data from the client device 180 using any supported communication protocol. In step 520, the OSU 130 may verify that the identification data specified in the subject name matches the device identity provided by the client device 180 in the certificate request of step 450. In some embodiments, the OSU 130 may query the client device 180 using any supported protocol, and the specified device identification data may be matched to the device identification data returned by the client device 180 Can be verified. In either case, this identity check can prevent a possible malicious device from pretending as a client device 180. In step 520, if the device identification check is affirmative, the OSU server 130 may include the identification data in the certificate registration request of step 455. [ The CA server 135 may then include the identification data in the subject parameter 705 of the certificate issued in step 460, as illustrated by the client certificate 700 (Fig. 7).

If the certificate signing request is verified to be valid, the OSU 130 may proceed to the registration process for authentication of the device certificate according to other rules specified in the HS2.0 specification. Also, the OSU 130 operating in conjunction with the CA server 135 infrastructure may provide an 'id-kp-HS2.0Auth' object, or similar object, to the EKU list 710 included in the issued X.509 certificate Lt; RTI ID = 0.0 > other < / RTI >

While the present invention has been shown and described in detail in the drawings, it is to be understood that the invention is not limited to the disclosed embodiments, but is capable of many and many different embodiments without departing from the invention as described and defined by the following claims Rearrangements, variations, and substitutions of the present invention are possible.

Claims (18)

Receiving a certificate signing request from a mobile network access device at a server;
Forwarding the certificate signing request to a certificate issuing authority, provided that the certificate signing request includes a network access standard that is the same as the predetermined value
Way.
The method according to claim 1,
Receiving a certificate signing request from the mobile network access device, and forwarding the certificate signing request to the certificate issuing authority, provided that a message containing device identification data has previously been received from the mobile network access device Included
Way.
The method according to claim 1,
Wherein the predetermined value specifies a hotspot 2.0 (HS2.0) or a later standard
Way.
The method according to claim 1,
The predetermined value is passed through an extended key usage (EKU) key purpose field
Way.
Receiving, by a network server, a network access request from a client via a network, the access request including an access certificate;
Determining a key objective associated with the access certificate by the network server;
Accepting, by the network server, access to the network service to the client on condition that the key objective is a predetermined key objective
Way.
6. The method of claim 5,
Wherein the predetermined key objective is an access to the hotspot network
Way.
The method according to claim 6,
The hotspot network may be a hotspot (HS2.0)
Way.
6. The method of claim 5,
The method further comprises refusing network access to the client on condition that the certificate authority determines that the certificate provided by the client has been revoked
Way.
6. The method of claim 5,
Wherein the access certificate includes an expiration key that includes the key purpose in an extended key usage field
Way.
Receiving a certificate enrollment request from a mobile network access device at a certificate authority server over a network;
Providing, by the certificate authority server, a signed network access certificate to the mobile network access device, provided that the certificate enrollment request includes a network access standard that is the same as the predetermined value
Way.
11. The method of claim 10,
The signed network access certificate comprising device identification data identifying the mobile network access device
Way.
11. The method of claim 10,
The network access standard specification specifies the hotspot 2.0 (HS2.0) or later standard
Way.
11. The method of claim 10,
The network access standard specification is transmitted in the EKU_key_purpose field of the signed network access certificate
Way.
Receiving, by a mobile network access device, a certificate for access to a service provider network;
Sending, by the mobile network access device, a certificate signing request to a service provider network server, the certificate signing request comprising a network access standard specification;
And receiving at the mobile network access device a signed access certificate comprising the network access standard specification
Way.
15. The method of claim 14,
Further comprising, by the mobile network access device, providing device identification data to a network access server,
Wherein the signed access certificate comprises the device identification data
Way.
16. The method of claim 15,
The device identification data is conveyed in a subject field of the signed access certificate
Way.
15. The method of claim 14,
The network access standard specification specifies the hotspot 2.0 (HS2.0) or later standard
Way.
15. The method of claim 14,
The network access standard specification is transmitted in the EKU_key_purpose field of the signed access certificate
Way.

Images