Patent Application
20180013782
Multi-factor authentication refers to any authentication that uses more than one factor. Multi-factor authentication may be used to strengthen the authentication of a user. An example two-factor authentication is based on a user's identity (ID) and password as a first authentication factor, and a hardware/software-based token as a second authentication factor. A user ID and password may be used to authenticate the user's presence, and the token may confirm the user's possession of the device on which the token functionality resides. Example authentication factors include user identities with corresponding passwords, tokens, and biometrics/behavioral aspects of a user.
Users (or devices) often maintain continuous access to a service, which is provided by a service provider (SP) on a network. For example, a user equipment (UE), using a browser or local application for example, may maintain a persistent connection to a service. While access may be persistent, current approaches often do not require further authentication to be performed after the user is authenticated for initial access, thereby creating a potential security vulnerability. Alternatively, in some cases users are forced to periodically re-authenticate using intrusive mechanisms, which creates an authentication burden for the users.
As described herein, the authentication burden on users may be lessened without compromising security. Further, different service providers may periodically authenticate users to their own levels as desired, as described herein. Methods, devices, and systems are disclosed herein that use a multitude of authentication factors and associated authentication functions to perform a continuous authentication, thereby providing a risk-based assurance assessment with reduced friction. Appropriate authentication factors and functions may be invoked on a periodic basis to maintain a certain authentication assurance level (AAL), which is referred to herein as an assurance or authentication threshold (AT) or an authentication assurance threshold. The AAL may decay over time and may be refreshed periodically. In an example embodiment, an authentication assurance level associated with an entity is periodically computed. The authentication assurance level is compared to an authentication threshold. Based on the comparison, it is determined whether one or more fresh authentication factors need to be performed to achieve the AT. The authentication assurance level may decay as a function of time. The authentication threshold may be based on a policy of a network, service, or application network.
A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:
By way of an example use case, a user wants her personal emails to be automatically updated from a server onto her smartphone on a regular basis. Traditionally, if an email client is present on the smartphone, the emails are regularly updated from the server to the client email application on the phone, and when the user opens the client email application, the user has access to the emails. The phone may have an option to lock the phone when an inactivity period is exceeded. The phone may be unlocked if the user supplies an appropriate PIN/Password. Some users may decide that it is too disruptive to use passwords in order to unlock the phone, and therefore they might not enable any PIN/Password. In such scenarios, anyone who is in possession of the phone is able to obtain the contents of the phone. For example, contents that can be obtained might include emails from the client email application, which can create a serious security condition because many services depend upon a person's access to email to perform sensitive operations (e.g., “password” reset operations). In some cases, users may configure the inactivity lock period to be large (e.g., 30 minutes) before the phone locks. In such scenarios, the security risk is reduced as compared to users who do not lock their phones at all, but there may be a large window (e.g., 30 minute) within which someone may pick up the phone and have access to the contents of the phone. Another example issue associated with locking phones is that in order for the user to unlock the phone she may have to enter her PIN/Password frequently, which may be an irritant that causes the user to shorten the password or to increase the inactivity period to a larger time interval, thereby decreasing the security of the phone and contents associated therewith.
Embodiments described herein use a multitude of authentication factors that are aided by associated authentication functions to perform a continuous authentication, thereby providing a risk-based assurance assessment with reduced friction. Appropriate authentication factors and functions may be invoked on a periodic basis in order to maintain a certain authentication assurance level (AAL), which is referred to herein as an Assurance Threshold (AT). The AAL may decay over time and thus may be refreshed periodically. Embodiments described herein allow a user to experience less friction while leveraging authentications with a higher assurance level. By way of example, a user may wear a biometric sensor (e.g., EKG) device (e.g., a band around the wrist or a pulse rate monitor) that provides biometric readings for authentication. The device may be paired with a smartphone, for example, using Bluetooth. In some cases, the AAL that can be obtained as a result of the biometric authentication (e.g., EKG) may be classified as “Medium” or some quantitative value (e.g., a value 10 on a scale of 1 to 16 where 16 represents a high level of assurance). The AAL may have an associated authentication decay value, which may be based on a time component. In some cases, each application may have its own required assurance level (ALreq). The ALreq may be a quantitative value or a qualitative (e.g., ALreq=Low, Medium, or High). In one example, users can be provided access to applications that require a “Medium” AAL or less, without requiring an authentication in addition to one authentication factor having a “Medium” AAL. The AAL may be recomputed periodically because the current AAL varies, for instance decays, as a function of time. As described below, the AT may take into consideration the decay process associated with each of the authentication functions/factors. The AT may be chosen such that it provides access to commonly used applications, or the AT may be chosen based on the ALreq of a majority of the applications.
In an example, a given ALreq represents the assurance level required by an application for accessing the application. Thus, the Alreq may be the assurance threshold that a user must achieve in order for that individual application to provide access to the user. The AT may be configured by policies and may reflect the AAL that a given system would like to maintain over a certain period. The period may vary based on various variables such as, for example, time of the day (e.g., period is smaller during the day while it is longer during night times). In one example, a difference between the AT and the ALreq is that the AT is a value that is chosen system-wide, which is appropriate for a majority of applications or services or commonly used services (e.g., based on system policies), whereas the ALreq applies to an individual application or is service-specific (e.g., dictated by application policies). In some cases, when the AAL of the user/system falls below the AT because of decay in the freshness of the authentications, then a fresh authentication is performed in order to maintain the AAL above the AT. In certain cases, the AT may vary depending upon policies (e.g., an AT may be reduced during inactive periods such as night times, weekends, etc.), and thus access to certain services or applications may be curtailed, in a seamless manner, when the AT is varied. The continuous authentication functionalities described herein may be managed, orchestrated, and asserted locally, via the network, or via a hybrid-approach.
As described below, in accordance with an example embodiment, authentications are performed in a continuous manner while ensuring that the authentications are minimally invasive and disruptive to the user. At least some of the continuous authentication mechanisms may be carried out periodically to maintain a certain user AAL. During example continuous authentication implementations described herein, active authentications may be carried out using explicit or via implicit means. For example, active data sessions may provide indications related to an AAL. In some cases, re-authentication is performed that intrudes the user and disrupts service minimally. Continuous authentication implementations described herein may utilize behavioral aspects of a user. Example behavioral aspects include a user's commonly used vocabulary or speech patterns when talking or when sending an email/SMS, a user's frequently visited websites, a user's typing speed or pattern, a user's frequent physical location (e.g., city, country, work, home, etc.), or the like. Continuous authentication implementations described herein may utilize biometrics associated with a user. For example, a camera on a device may be used to detect or identify (e.g., via an iris scan) a user. Continuous authentication may also rely on detecting a heartbeat, detecting heat, detecting movement, detecting a person's gait, or the like. Continuous authentication implementations described herein may utilize one or more devices. For example, a second device may be detected by a first device, for example via Bluetooth.
Continuous authentications, which can also be referred to herein without limitation as periodic or active authentications, are authentications that may be carried out on a regular basis with or without the involvement of a user. For example, continuous authentications may be carried out based on a certain time interval. Alternatively, a measure of the Authentication Assurance Level (AAL) may be determined periodically, and then a decision may be made concerning whether further authentications need to be carried out. An example high-level architecture 100 of example continuous authentication functions is illustrated in
Referring to
Referring also to
In accordance with one embodiment, a given UE, for instance the example UE 102, may be paired with other devices or authentication factor functions that reside on the same device or on other devices. A user of the UE 102 may be associated with multiple authentication factors (1-N). A subset of the factors may be paired with the CAA 112 or the CAS 110 for providing continuous authentication. The authentication factors may cover password authentication (what one knows), device authentication (what one has), biometrics (who one is) and behavioral (how one behaves) factors. In some cases, the process starts by registering the UE 102 into a secure network or system. It will be understood that the UE 102 can be a mobile phone, tablet, or any other portable or static device with input interfaces such as a fingerprint scanner, video camera, touchscreen, etc. The registration of the UE 102 into the secure system may consist of identifying the UE 102 from a list of authorized devices in a database with information about the authentication features each registered device offers. This database might also hold relational information to match security levels with appropriate authentication mechanisms that can grant access at a particular security level.
In some cases, an identified and registered device can then be used as a source of authentications. For example, a registered device can be directly linked to a target device. The target device can be unlocked by using NFC tags, barcode scanning, Bluetooth pairing, Wi-Fi signal strength proximity awareness, geolocation, or any other method indicating that there is a close proximity to the target device. In some cases in which a direct link to the target device is not possible, the user requesting access can directly specify the device to access by manually searching for an identifier of the device or by searching the target device from a list of targets.
Having identified and/or paired the target and authentication devices, in accordance with an example embodiment, the security system consults an internal database to match the required access (or security level) with available authentication mechanisms from the external device. If a match is found and external authentication is accepted by the system, the target device can give an indication to confirm the pairing. Otherwise the process may be finished.
When pairing is confirmed, the external authenticating device may prompt the user, who is requesting access from a service provider, with one or more choices to authenticate by presenting his/her security credentials. The security system may confirm the validity of credentials and may allow for a predetermined number of failed attempts before exiting the system. The maximum number of attempts can be related to behavioral analysis concerning how a user is interacting with the security system. The maximum number of attempts might be determined based other inputs from the authenticating device or any other additional devices (e.g., security cameras). Once a given user is authenticated, the security system may monitor various parameters, such as, for example, usage, time validity of validation, etc. to retain validation or to revoke authentication.
As described herein, selection of a given AT may be based on policies that take into consideration the ALreq of user applications or service provider applications. In some cases, the AT may be based on other factors (e.g., a decay factor of respective authentication factors). An example table for the selection of AT is presented below in Table 1, which shows example applications and their associated assurance level requirements (ALreq).
The outcome of each authentication factor may be binary, wherein the result is either success or failure, or some soft values, which may be interpreted accordingly based on policies. The resulting assurance level for a given factor is based on the result and a freshness factor which is configurable for each factor.
Referring now to
In some cases, if freshness for an authentication factor is configured with a decay factor and type, then the output of authentication, AL, may be determined using an exponential decay or a linear decay. Exponential decay refers to an exponential decay function, where decay is represented by the provided parameter. Linear decay refers to a linear decay of the freshness, from the current level to zero at the time specified by the freshness time.
By way of example, still referring to
Continuous authentication described herein may be network-based, device-based, or a combination thereof. Referring to
Referring to
In some cases, when a given UE is inactive (e.g., when a UE is sleeping) and a CAME is not able to continuously authenticate the user, then the AT might not be achievable, and therefore access to services whose ALreq is higher is restricted and a full authentication process may need to be carried out. A behavioral engine may be part of the CAME, and the behavioral engine may be able to learn the authentication patterns and the AL achieved, for example on a day or time basis. For example, if a particular UE that is expected to be inactive during a certain time of the day is actually active, as indicated by a higher than usual AAL, further authentication using a different factor may be triggered in order to determine the cause for such anomalous behavior.
Some authentications, which may be referred to as implicit authentications, may be carried out so that there is no interruption in user experience. Once a user has been authenticated, certain parameters (e.g., session keys, usage patterns, implicit indications, etc.) may be used for continuous monitoring and authentications. In accordance with an example, embodiment, such an implicit authentication process may use session keys for monitoring a registered user's presence. Once the session keys expire, then a re-authentication may have to be carried out.
Implicit and Continuous Authentications may be carried out using mechanisms such as, for example, Biometric, Behavioral, Possession of Device (based on device usage and connectivity) and what a user knows.
In some cases, when a user is connected to a network (wireless/wired) and authenticated a security association may be established. As a result of the establishment of a security association/context, a Master Session Key (MSK) may be established. Derivative keys for performing integrity protection, message authentication, encryption, key generation, and key encryption may be generated from the MSK.
In some cases, a given UE may use security contexts (e.g., keys) to provide an appropriate type of security functionality required for the type of traffic being sent or received. For example, if the UE is sending a signaling message, then the message may be integrity protected using the appropriate key for deriving a Message Integrity Code (MIC). Similarly, if data traffic is being sent from the UE, then the data may be encrypted using the Ciphering Key (CK).
If a user continues to use a service and if the same key (e.g., MSK) or derivatives thereof are being used by the UE for protecting the traffic that originates from the UE, then the fact that the UE continues to communicate with the same or derivative key may imply, with a high degree of assurance, that it is the same user that setup the connectivity, thereby contributing to the continuous authentication AAL.
Referring now to
In accordance with the illustrated embodiment, at 701, the UE/User 750 requests access to a Service via the SE 752. The SE 752 may host an ACE. The SE 752 may include a Wi-Fi AP, LTE eNodeB, MME, Web Services/Application portals (RP/SP), IPSec Gateway, or any other entity with which the User/UE 750 requests service and may have a security association established therewith. At 702, the UE/User 750 may have an authentication entity associated with the identity that is being used to perform an authentication with the CAME 754. The identity may correspond to the UE or the user of the UE. The Authentication Entity may include a Radius Server, AuC/HSS, or Active Directory/LDAP. Alternatively, the Authentication Entity may be part of the CAME Functionality or provide inputs to the CAME 754. As mentioned above, the CAME 754 may have a local proxy function (the CAA) and a network function (the CSS). The SE 754 may communicate with the CAME 754 in order to authenticate the UE/user 750. At 703, the UE/user 750 is authenticated with the CAME 754. This authentication may which may involve a series of steps, and may be based on one or more protocols (e.g., EAP, TLS, GBA, Kerberos, IPSec, etc.). As a result of the UE/user 750 authentication, a Master Session Key (MSK) may be generated. Depending upon the technology being used, the MSK may be generated based on the standards associated with the SE 752 and the UE/user 750. An example MSK is 256/512 bit key that is cryptographically generated using mechanisms such as the mechanisms described in the EAP-AKA′ protocol. Further derivative keys may be generated from the MSK. At 704, the CAME 754, for example an MFAS that encompasses the CAME 754, may send an assertion vouching for the identity of the UE/User 750. For simplicity, the MFAS and the CAME may be referred to collectively as the CAME/MFAS. The CAME/MFAS may optionally provide a part of the MSK, the MSK, or a derivative of the MSK to the SE 752. The UE 750 may be able to generate the MSK on its own, or it may be provisioned with the MSK or a derivative of the MSK by the CAME 754. The SE 752 and the UE/user 750 may generate derivative keys that may be used for securing the session between the UE/user 750 and the SE 752. Alternatively, the session keys that are generated may not be dependent upon the MSK generated as a result of the authentication process between the UE/user 750 and the CAME 754. The session keys may be generated out of a TLS connection between the UE 750 and the SE 752.
Still referring to
At 708, in accordance with the illustrated embodiment, based on examination of the assertion in the response received from the SE 752 or the UE 750, the CAME 754 updates the achieved assurance level of the UE/user 750. The above-described assertion message (at 707a and 707b) may be protected against tampering, replay, and eavesdropping by cryptographical or non-cryptographical means. The assertion may include a nonce, time stamp, sequence counter value, or other token to ensure protection from a replay attack. The assertion may also be cryptographically protected for integrity and/or confidentiality using a derivative of the MSK or Ks (or GBA using Ks_NAF), or using any other key that may facilitate secure communication between the entity in the UE that created the assertion, and the final on UE or off UE entity (e.g., network) that receives the assertion. The assertion may include an assurance level that indicates the quality of the authentication. For example, the assurance level may be based on when the last confirmed authentication was carried out with updates based on, for example, freshness and use of continuous communications based implicit authentication. Example mechanism of generating the assertion are described herein, though it will be understood that other means of processing the assertion locally on the UE or in the network can be performed to facilitate multi-factor authentication as desired. The multi-factor authentication can include a UICC based device authentication with the continued connectivity between the UE and SE as one factor of the multi-factor authentication system. Further, multiple authentication factors may be bound together.
Below is description, by way of example, of authentication methods in an LTE system. It will be understood, however, that the concepts disclosed herein are not limited to LTE, and thus may be applied to any communication system as desired, for example GSM, WCDMA, Wi-Fi, etc.
Now an implicit authentication mechanism based on the LTE authentication process is described in accordance with an example embodiment. Upon the UE initial attachment or re-attachment to the serving network, the UE is being authenticated by its Home Network using the EPS AKA (Authentication and Key Agreement) protocol. In the course of AKA, serving network or SE, acting as Authenticator, uses Security Mode Command (SMC). For two security areas in EPS, NAS and AS, two distinct SMCs are being produced, NAS SMC and AS SMC. Each of them, when issued by the serving network is ciphered and integrity protected by the respective NAS and AS ciphering and integrity protection keys.
When an ME part of the UE can receive SMC, verify integrity of SMC, and read SMC correctly, it means that the UE has been able to positively authenticate the serving network, and that the serving network was able to positively authenticate and authorize the UE for access to the serving network.
In some cases, with an appropriate API, as illustrated in
It is possible to initiate NAS Security Mode Command (NAS SMC) from an ME in Tracking Area Update (TAU) command/procedure. For example, a TAU can be initiated by the UE in some cases per 3GPP TS 24.301, which is incorporated by reference as if the contents of which are set forth herein. Portions of 3GPP TS 24.301 are reproduced below for convenience:
The abridged list of TAU triggers is reproduced as an example only. The complete list of TAU triggers is specified in TS 24.301. Any of the TAU triggers specified may be used to create an on demand SMC or a new SMC message may be specifically created for the implicit authentication.
The procedure may be initiated by a given UE in ECM-IDLE state or ECM-CONNECTED state. It is ECM-IDLE state that is most appropriate for triggering subscription authentication through the application/modem API; however, whether it is IDLE or CONNECTED can be driven by authentication policy. One of the possible ways to trigger is zeroing the periodic TA update timer through the same API.
As stated above, the SMC is an implicit assertion of MNO access authentication. However, anytime the UE can subsequently verify integrity and decipher network messages (either NAS or AS), such an event indicates that the UE at some point in time successfully performed MNO subscription and access authentication, which resulted in the SMC. This leads to a mechanism for performing continuous authentication, as recognized herein. For example, an acceptable level of continuous authentication strength may be maintained by using two interdependent timers.
Referring now to
Referring to
Referring to
In summary of the above, the UE can generate an assertion with respect to an access authentication (e.g., AKA) success based on the successful interpretation (e.g., integrity and replay protection) of the SECURITY MODE COMMAND. Clause 5.4.3.2 of TS 24.301 Rel 12 describes the SECURITY MODE COMPLETE message as a response to the SECURITY MODE COMMAND (e.g., SMC). The UE issues a SECURITY MODE COMPLETE message that completes access authentication from the UE point of view, and the receipt of the SECURITY MODE COMPLETE by the MME completes the access authentication from the network point of view. The MME may generate an assertion indicating success in a similar manner to that described for the UE, and relay the assertion to other network entities such as the CAME. Continuous authentication may also be performed by virtue of successfully verifying integrity and deciphering network messages from the UE.
In accordance with an example embodiment, an appropriate API between an application server and the mobile networks enables the application server to initiate an authentication of the UE subscription. As an illustrative example, when the application server wishes to perform an authentication of the UE subscription, it may build an identifier of the Home MNO Network (e.g., URI of HLR, AuC) by analyzing the UE mobile identity (e.g., MSISDN, IMSI, etc.). The UE identity may be registered and known at the application server and bound to the user of the UE. The application server may then query the Home MNO Network using the derived identifier and then receive back the identifier of the Serving MNO Network (e.g., URI of the serving MME). The application server may then contact the Serving MNO Network and request an access layer authentication. An access layer authentication may be derived from an implicit interpretation of the SECURITY MODE COMPLETE message or from successfully verifying integrity and/or deciphering of network messages from the UE on a frequent and/or continuous basis. The Serving MNO Network provides an authentication assertion to the application server after a successful access layer authentication.
The application server may be redirected to either the Home or Visited Serving Network, for example, depending on where the UE is located (e.g., home or roaming scenario). Thus, in some cases, the application server does not need to distinguish between home and roaming use cases.
The authentication assertion may be signed and/or protected by a variety of methods so as to enable verification by the application server. To protect the assertion and communications, a security association may be setup between the UE and the application server, or between the Serving MNO Network and the application server as appropriate. An assertion signing key may be established between the UE and the application server and/or the Serving MNO Network and the application server as appropriate.
Additionally, an authentication transaction ID or context reference may be generated that identifies the authentication that was carried between the UE and Serving MNO Network. In some cases, this transaction ID is known to both the UE and Serving MNO Network, and may be communicated to the application server by either party. The transaction ID may be generated by the UE or Serving MNO Network, and communicated to the other party or mutually generated.
Referring now to
In accordance with the illustrated example, Jane tries to unlock the UE 202a at 9:30 AM. This triggers the UE 202a in order to initiate a local authentication of the user 202b by invoking the services of the MFAP 206. The preferred local authentication factor may be a biometric fingerprint authentication. It is assumed for exemplary purposes that in order for Jane to be able to unlock her phone, the assurance level required by the access control mechanism is “Medium”. Therefore, the assurance level obtained based on the authentication(s) of Jane that are performed must be at least equal or greater than a “Medium” in order for her phone to be unlocked. Thus, for example, if Jane is only authenticated by a password that has an AAL=low, then the password authentication will be insufficient to unlock her phone.
At 1, the MFAP invokes the local biometric app 204. At 2, the biometric app 204 starts the biometric fingerprint authentication process and requests the user 202b (Jane) to swipe her fingers on the biometric sensor present on the UE 202a. At 3, Jane swipes her finger on the sensor, and the generated fingerprints are then provided to the biometric app 204. At 4, the biometric app 204 generates Jane's fingerprint model and then performs an authentication of the generated fingerprint model as compared to the one that was stored in the local secure database during registration. The biometric app 204 then creates an assertion based on the authentication result. At 5, the biometric app 204 sends the assertion to the MFAP 206. At 6, it is assumed in this example that a successful local fingerprint authentication delivers an assurance level of “Medium”, and therefore an access control entity (ACE) provides Jane with access to her phone features based on the assurance level requirement. At 7, the MFAP 206 generates a signed assertion. The signed assertion may indicate the AAL achieved (e.g., Medium), and may also contain specific details indicative of, for example, the authentication process, accuracy of the fingerprint matching, fingerprint sensing matching software, fingerprint reader information, or the like. This information may be signed by the MFAP 206 using public keying mechanisms or by using a symmetric key shared between the MFAP 206 and the MFAS 212. At 8, the signed assertion may be sent via the browser 208 or via a secure connection (e.g., TLS, EAP etc.). At 9, the browser 208 sends the signed assertion to the MFAS 212 via a HTTPS connection, or it is communicated directly by the MFAP 206 to the MFAS 212 in a secure manner (e.g., by means of a TLS connection).
Still referring to
Still referring to
At 21, in accordance with the illustrated example, the MFAP 206 determines that no further authentications are to be carried out if the achieved AL is greater or equal to the requested AL. The MFAP 206 may perform an authorization check with Jane to see if she had indeed authorized to perform the operations on the MyShop portal using a client notification (e.g., by means of SMS, pop-up, etc.). The MFAP 206 may create a new assertion using information from fresh (previously conducted) authentication results along with optional authorization information. At 22, the MFAP 206 forwards the signed authentication (Auth) results via the browser 208 (in some cases, this is optional only if the browser 208 is used as an intermediary). At 23, the browser/app 208 forwards the signed auth results via a HTTPS connection (in some cases, this is optional only if the browser 208 is used as an intermediary), or the results may be sent directly by the MFAP 206 to the MFAS 212 using a TLS connection. At 24, in accordance with the illustrated example, the MFAS 212 verifies the Auth results. Because no new authentications were carried out, a new ATID might not be derived. This (whether to derive a new ATID) may be left to implementations as desired. At 25, the MFAS 212 sends a signed assertion to the RP 210a: MyShop. At 26, the RP 210, upon verifying the signed assertion from the MFAS 212, provides Jane with access to the RP 210a: MyShop. At 27, the MFAS 212 may optionally send a notification to the MFAP 206 along with a new ATID (optional) that signifies a successful authentication. At 28, in accordance with the illustrated example, if a new ATID was generated, then the MFAP 206 registers that in the MFAP user database 214.
Still referring to
At 30, based on the new AL requested by the RP 210a, and taking into consideration the existing fresh authentications, the MFAS 212 may request further authentications of Jane. The MFAS 212 sends the request to the MFAP 206 along with an optional request for Jane's authorization and a Nonce/Handle (optional). At 31, the browser/app 208 forwards the request to the MFAP 206 (optional). This may be send by the MFAS 212 directly to the MFAP 206. At 32, the MFAP 206 is invoked by the browser/app 208. At 33, based on the AL requested by the RP 210a and the current AL achieved by Jane, the MFAP 206 determines that a password-based authentication may have to be additionally carried out. Also optionally, the MFAP 206 may request that Jane authorize the transaction. The authorization that might be required in order to perform the transaction may be carried out using another channel (e.g., SMS/text or other means). Further, the MFAP 206 may also optionally request authorization for releasing Jane's address. At 34, in accordance with the illustrated example, password authentication is carried out locally and authorizations are obtained from Jane. At 35, the MFAP 206 creates a signed assertion of the authentication results and authorization information, and sends the assertion, via the browser 208 (optionally may be sent directly from the MFAP 206 to the MFAS 212 using TLS connection). At 36, signed results are sent to the MFAS 212 using an HTTPS connection. In some cases, this may be sent directly from the MFAP 206 using a TLS connection.
At 37, the MFAS 212 verifies the signed auth results and generates a new ATID using new Nonce2/Association Handle2. The MFAS 212 registers the ATID along with the auth results, timestamps, and the AL achieved in the user profile DB 212. At 38, the MFAS 212 sends the assertion to RP 210a: MyShop. At 39, Jane is authenticated and provided with access to MyShop and Jane completes the transaction on the RP 210a: MyShop and successfully buys the television. At 40, the MFAS 212 sends the ATID so that it can be registered with the MFAP 206. Optionally, the MFAS 212 instructs the MFAP 206 to derive the ATID on its own using the Nonce 2/Handle 2, and other keying material that is available with the MFAP 206. At 41, the MFAP 206 registers the ATID within the user profile DB 214 on the MFAP 206. Referring to 42, at 11:00 AM, Jane wants to announce on another portal, RP 210b: MyFace, that she had just bought a TV on MyShop at a bargain price. Jane enters her nickname on the MyFace website. At 43, the browser/app 208 queries the MFAP for an existing ATID. At 44, the browser/app 208 sends the query to the MFAP 206. At 45, the MFAP 206 responds with the latest ATID, which may be expired or fresh. At 46, the browser/app 208 replaces the nickname with the ATID (e.g., c324848df213ee842aa32b@idp.interdigital.com) and forwards the message to the RP 210b: MyFace. At 47, in accordance with the illustrated example, the RP 210b: MyFace determines the required AL based on risk-based access for that service. At 48, in accordance with the illustrated example, MyFace performs Discovery and Association based on the ATID information that was provided, which contains Jane's IdP information, and provides the MFAS 212 with the AL that is required.
At 49, in accordance with the illustrated example, the MFAS 212 determines that the AL required is less than or equal to the AL that has been freshly achieved so far, and therefore only requests Jane's authorization. The MFAS 212 sends the request to the MFAP 206 via the browser 208 or using direct secure connection (e.g., TLS), which may be sent directly by the MFAS 212 to the MFAP 206. At 50, the browser/app 208 invokes the MFAP 206. At 51, the MFAP 206 determines that only a user authorization is required. At 52, the MFAP 206 may send an authorization request to Jane using another channel (e.g., via another device, SMS, other wearable device). Jane provides her authorization. At 53, the MFAP 206 creates a signed assertion using the authorization as part of the message. At 54, the MFAP 206 sends the signed assertion to the MFAS 212 via the browser 208 (may be sent directly). At 55, the signed results are forwarded by the browser/app 208 to the MFAS 212 using a secure protocol (e.g., TLS, HTTPS.). At 56, after verifying the assertion provided by the MFAP 206, the MFAS 212 creates a signed assertion and forwards it to the RP 210b: MyFace. The MFAS 212 registers the authorization information in the user profile DB 212. At 57, the RP 210b: MyFace authenticates Jane, determines that Jane has been successfully authenticated to MyFace, and informs connected users that Jane bought a TV on MyShop.
Referring now to
A user that uses multiple devices may wish to isolate the “freshness” of successfully authenticated factors in one device from those in another device. Without isolation, an attacker, with the knowledge that the user has just performed authentication with a fresh password factor, may log-in to a RP via a browser without the OP prompting the user to provide a password. Furthermore, without “freshness” isolation between devices, “assurance level creep” may occur in a scenario in which a factor with a low assurance level is considered fresh for the same factor in another device, but is designated with a higher assurance level.
In MFAS, its database has policy/log entries for each device registered under a user. Based on the capabilities of a device, it may have a set of factors for authentication, different from the set in another device. The set may change based on the RP identity according to the service level agreement with the RP. The same factor in different devices may provide different assurance levels. e.g. the finger print factor on an Apple device may provide more assurance than the same factor in another device by a different manufacturer
Each MFAP corresponding to a user/device has a MFAP id. To enforce the freshness isolation, the timestamp and retry count of the same authentication factor is kept separately for each MFAP id. Each MFAP has its own Long-Term-Secret and an ATID is associated with an MFAP id and is a temporary identifier of MFAP id. If the ATID is only used between MFAS and MFAP in a secure channel, the ATID can also be used as a token representing a still valid authentication.
A “default device” is a device that is not registered by the user, such as a browser on a desktop computer for example. The authentication factor for a default device may be generic, such as password for example. A default device does not provide MFAS with a MFAP ID or ATID. This triggers the MFAS to use the one or more factors configured for the default device to authenticate the user. The MFAS may choose not to store the timestamp of default device authentication, i.e. disregarding the freshness of the authentication, because it may not be able to distinguish whether two authentication attempts are from the same “default device”. Alternatively, the http session cookie (transported in a secure channel) with appropriate session timeout, can be used to determine the “freshness” of the prior authentication via the default device.
In some cases, because of the isolation of “freshness” among devices of the same user, and because the set of configured authentication factors can be different for different devices, MFAP ID/ATID (or the lack of device IDs) are conveyed to the MFAS during the authentication, in accordance with an example embodiment. Referring to
In accordance with the illustrated embodiment, at 0, the MFAP 1204, in particular a CAA of the MFAP 1204, and the MFAS 1210, in particular a CAS of the MFAS 1210, discover each other. At 1, the user/UE, via the browser/app 1206, provides a user ID to the RP 1208. At 2, the RP 1208 determines a required AL that corresponds to the service that the user requested. At 3, the RP 1208 and the MFAS 1210 discover each other and associated with each other. At 4, the RP 1208 sends an HTTP redirect message to the UE, via the browser/app 1206. The redirect message may include the required assurance level. At 5, the authentication request is redirected to the MFAS 1210. At step 5a, the MFAS 120 sends, to the browser 1206, an html page, which may contain a javascript procedure to trigger a custom soid.scheme URL or trigger the MFAP 1204. In accordance with the illustrated example, the query string of the custom URL indicates the MFAP ID query, a nonce, and an association handle. If the custom URL is supported, the MFAP 1204 pops up a timer that brings the browser 1206 to a fallback URL at timeout. At step 5b, if 5a succeeds, the MFAP 1204 returns its MFAP ID or ATID from a previous authentication instead of its own http(s) agent. The MFAP ID or ATID is signed by PSK (which can be reconfigured every few months). The message at 5b also may include the nonce and the association handle. The message at 5b is sent via the browser/app 1206. In accordance with the illustrated example, when the MFAS 1210 receives the MFAP ID/ATID, it adds the received ID to a session attribute. At 5c, the timer that started at step 5a times out, and the browser 1206 may send an http request to a fallback URL. If MFAS ID/ATID is in the session attribute (e.g., step 5a was successful) the MFAS 1210 may continue with step 5d. If MFAS ID/ATID is not in the session attribute (e.g., 5a was not successful), the MFAS may skip illustrated step 5d and continue with step 6. For example, at 6a, the MFAS 1210 may return an authentication page based on a “default device.” At step 5d, in accordance with the illustrated example, the MFAS 1210 sends back an HTML page with javascript to close the browser tab.
Still referring to
Referring still to
In an alternative embodiment, step 1 of
With continuing reference to
Continuing with the example above, in some cases, the legacy RP may see the same user (with different devices) as different users, because different OpenIDs were presented at the time of login. To address this issue, the MFAS 1210 may use part of the OpenID Connect procedure to return an ID Token with the authentication response message. The RP 1208 can be enhanced to use an ID token to query the actual user identity with the MFAS 1210.
The MFAP/Addon may need to be configured with the textfield name/id of the RP login page. In some cases, if there is a redesign of the RP login page, the MFAP/addon database is changed accordingly.
In some cases, with respect to the desktop browser or mobile browsers other than dolphin, the plugin is not present. In an example, the user may log in using its original OpenID, and the “default device” policy applies.
In yet another alternative embodiment, the dolphin plugin alters the http request in step 5 instead of step 1. Unlike the above-described embodiment, the Legacy RP sees the user (with different devices) as the same user. The OpenID redirect is detected by addon using the well-known openid.x fields. The MAP/addon is agnostic to RP login page redesign. The plugin does not change openid identifier itself but changes the authentication request message to convey the MFAP id/ATID instead. For example, the ATID can be used as a secret token associated with a not-expired authentication, if it is transported in a secure channel between the browser 1206 and the MFAS 1210.
Referring now to
An example of using multiple MFAPs within a user device and the respective AT is shown in Tables 2 and 3.
From Table 1, it can be observed that the application App1 has an ALreq=“Medium,” while App2 has ALreq=“Low”. The AT that has been selected and configured is “Low”. Therefore, at any instance, the user is authenticated on a continuous basis in order to maintain an Assurance level=low and thereby, the user is able to access App2 seamlessly without requiring any additional authentication. However, if a user requires access to App1, then an extra level of authentication may have to be carried out because it requires an ALreq=Medium.
As it can be observed from Table 3, which depicts a different example scenario, the apps App3 and App4 have ALreq=High, while App5 has ALreq=Medium, and the AT that has been selected and configured is “Medium”. Therefore, at any instance, the user is able to access App5 without requiring additional authentication. However, if the user were to access App3 or App4, the user may have to be authenticated using certain factors of authentication so that the cumulative Authentication Assurance Level achieved is equal to or greater than “High”.
The MFAP 1404a and the MFAP 1404b may share a common API in order to access the various devices/device drivers that might be required to initiate authentication factors and/or obtain results of explicit or implicit authentications. However, the interpretations of the assurance levels associated with each of the authentication factors may be dependent upon the MFAP/MFAS or the security domains to which they belong. The MFAP 1404a and the MFAP 1404b (or any additional MFAP) may belong to different security domains, and therefore have different policies that interpret the assurance levels differently.
In some cases, it is the presence of user-controlled devices and their configuration/interworking with each other that creates yet another environmental authentication factor which can be continuously monitored. Such continuously monitored environmental authentication factor can be used as one of the additional authentication factors (e.g., location, relevant location, time of access, etc.) by employing its own MFAS/MFAP.
Referring now to
In one example, the MFAPs within each of the UEs associated with each user performs continuous authentication of one another. For example, a first MFAP 1504a associated with the first user/UE 1502a may act as the master MFAP, and a second MFAP 1504b may act as a slave MFAP. In other embodiment, the users 1502a and 1502b may belong to a group, and thus their authentications may be performed using group mechanisms described above. For example, MFAPs that reside in each of the group member's UEs can perform continuous authentication of one another. Alternatively, a transitive approach may be used. By way of example, if User A is continuously authenticated with User B, and if User C is continuously authenticated with User B, then User A might not need to be continuously authenticated by User C. Thus, User A and User C may have the same assurance level with one another, even though they are not being directly authenticated with one another.
Thus, as described above, an authentication assurance level associated with a first entity (e.g., a UE) may be computed by a second entity (e.g., a CAME), wherein the authentication assurance level changes, for instance decays, as a function of time. The computed authentication assurance level may be compared to an authentication threshold that is based on a network policy. Based on the comparison, it can be determined whether a fresh performance of at least one of a plurality of different authentication factors is required to satisfy the authentication threshold. In response to determining that the fresh performance of one of a plurality of different authentication factors is required, at least one authentication factor may be invoked. Furthermore, the authentication assurance level, as described above, may be computed using at least one of the plurality of different authentication factors that have respective authentication assurance levels that change over time. The authentication assurance level associated with the first entity may be computed periodically. Alternatively, or additionally, the authentication assurance level may be computed in response to an event. The CAME may include a server-side continuous authentication server (CAS) that communicates with the first entity over a network, and a continuous authentication agent (CAA) that resides locally on the first entity. The first entity may be registered with a multi-factor authentication server (MFAS), such that authentication capabilities associated with the first entity can be retrieved from the MFAS.
In one example, the authentication assurance level decays linearly as a function of time. Alternatively, the authentication assurance level may decay exponentially as a function of time. Alternatively still, the authentication assurance level may decay in accordance with a step function that reduces to zero after a period of time. The plurality of authentication factors may each have a corresponding parameter indicative of how the assurance level contribution for each factor changes, for instance decays, over time.
As shown in
The communications systems 50 may also include a base station 64a and a base station 64b. Each of the base stations 64a, 64b may be any type of device configured to wirelessly interface with at least one of the WTRUs 52a, 52b, 52c, 52d to facilitate access to one or more communication networks, such as the core network 56, the Internet 60, and/or the networks 62. By way of example, the base stations 64a, 64b may be a base transceiver station (BTS), a Node-B, an eNode B, a Home Node B, a Home eNode B, a site controller, an access point (AP), a wireless router, and the like. While the base stations 64a, 64b are each depicted as a single element, it will be appreciated that the base stations 64a, 64b may include any number of interconnected base stations and/or network elements.
The base station 64a may be part of the RAN 54, which may also include other base stations and/or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base station 64a and/or the base station 64b may be configured to transmit and/or receive wireless signals within a particular geographic region, which may be referred to as a cell (not shown). The cell may further be divided into cell sectors. For example, the cell associated with the base station 64a may be divided into three sectors. Thus, in an embodiment, the base station 64a may include three transceivers, i.e., one for each sector of the cell. In an embodiment, the base station 64a may employ multiple-input multiple output (MIMO) technology and, therefore, may utilize multiple transceivers for each sector of the cell.
The base stations 64a, 64b may communicate with one or more of the WTRUs 52a, 52b, 52c, 52d over an air interface 66, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 66 may be established using any suitable radio access technology (RAT).
More specifically, as noted above, the communications system 50 may be a multiple access system and may employ one or more channel access schemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and the like. For example, the base station 64a in the RAN 54 and the WTRUs 52a, 52b, 52c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish the air interface 66 using wideband CDMA (WCDMA). WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and/or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and/or High-Speed Uplink Packet Access (HSUPA).
In an embodiment, the base station 64a and the WTRUs 52a, 52b, 52c may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may establish the air interface 66 using Long Term Evolution (LTE) and/or LTE-Advanced (LTE-A).
In other embodiments, the base station 64a and the WTRUs 52a, 52b, 52c may implement radio technologies such as IEEE 802.16 (i.e., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1×, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), and the like.
The base station 64b in
The RAN 54 may be in communication with the core network 56, which may be any type of network configured to provide voice, data, applications, and/or voice over internet protocol (VoIP) services to one or more of the WTRUs 52a, 52b, 52c, 52d. For example, the core network 56 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and/or perform high-level security functions, such as user authentication. Although not shown in
The core network 56 may also serve as a gateway for the WTRUs 52a, 52b, 52c, 52d to access the PSTN 58, the Internet 60, and/or other networks 62. The PSTN 58 may include circuit-switched telephone networks that provide plain old telephone service (POTS). The Internet 60 may include a global system of interconnected computer networks and devices that use common communication protocols, such as the transmission control protocol (TCP), user datagram protocol (UDP) and the internet protocol (IP) in the TCP/IP internet protocol suite. The networks 62 may include wired or wireless communications networks owned and/or operated by other service providers. For example, the networks 62 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 54 or a different RAT.
Some or all of the WTRUs 52a, 52b, 52c, 52d in the communications system 800 may include multi-mode capabilities, i.e., the WTRUs 52a, 52b, 52c, 52d may include multiple transceivers for communicating with different wireless networks over different wireless links. For example, the WTRU 52c shown in
The processor 68 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs) circuits, any other type of integrated circuit (IC), a state machine, and the like. The processor 68 may perform signal coding, data processing, power control, input/output processing, and/or any other functionality that enables the WTRU 52 to operate in a wireless environment. The processor 68 may be coupled to the transceiver 70, which may be coupled to the transmit/receive element 72. While
The transmit/receive element 72 may be configured to transmit signals to, or receive signals from, a base station (e.g., the base station 64a) over the air interface 66. For example, in an embodiment, the transmit/receive element 72 may be an antenna configured to transmit and/or receive RF signals. In an embodiment, the transmit/receive element 72 may be an emitter/detector configured to transmit and/or receive IR, UV, or visible light signals, for example. In yet an embodiment, the transmit/receive element 72 may be configured to transmit and receive both RF and light signals. It will be appreciated that the transmit/receive element 72 may be configured to transmit and/or receive any combination of wireless signals.
In addition, although the transmit/receive element 72 is depicted in
The transceiver 70 may be configured to modulate the signals that are to be transmitted by the transmit/receive element 72 and to demodulate the signals that are received by the transmit/receive element 72. As noted above, the WTRU 52 may have multi-mode capabilities. Thus, the transceiver 70 may include multiple transceivers for enabling the WTRU 52 to communicate via multiple RATs, such as UTRA and IEEE 802.11, for example.
The processor 68 of the WTRU 52 may be coupled to, and may receive user input data from, the speaker/microphone 74, the keypad 76, and/or the display/touchpad 78 (e.g., a liquid crystal display (LCD) display unit or organic light-emitting diode (OLED) display unit). The processor 68 may also output user data to the speaker/microphone 74, the keypad 76, and/or the display/touchpad 78. In addition, the processor 68 may access information from, and store data in, any type of suitable memory, such as the non-removable memory 80 and/or the removable memory 82. The non-removable memory 80 may include random-access memory (RAM), read-only memory (ROM), a hard disk, or any other type of memory storage device. The removable memory 82 may include a subscriber identity module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 68 may access information from, and store data in, memory that is not physically located on the WTRU 52, such as on a server or a home computer (not shown).
The processor 68 may receive power from the power source 84, and may be configured to distribute and/or control the power to the other components in the WTRU 52. The power source 84 may be any suitable device for powering the WTRU 52. For example, the power source 84 may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd), nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion), etc.), solar cells, fuel cells, and the like.
The processor 68 may also be coupled to the GPS chipset 86, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 52. In addition to, or in lieu of, the information from the GPS chipset 86, the WTRU 52 may receive location information over the air interface 816 from a base station (e.g., base stations 64a, 64b) and/or determine its location based on the timing of the signals being received from two or more nearby base stations. It will be appreciated that the WTRU 52 may acquire location information by way of any suitable location-determination method while remaining consistent with an embodiment.
The processor 68 may further be coupled to other peripherals 88, which may include one or more software and/or hardware modules that provide additional features, functionality and/or wired or wireless connectivity. For example, the peripherals 88 may include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands free headset, a Bluetooth® module, a frequency modulated (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, and the like.
As shown in
The core network 56 shown in
The RNC 92a in the RAN 54 may be connected to the MSC 96 in the core network 56 via an IuCS interface. The MSC 96 may be connected to the MGW 94. The MSC 96 and the MGW 94 may provide the WTRUs 52a, 52b, 52c with access to circuit-switched networks, such as the PSTN 58, to facilitate communications between the WTRUs 52a, 52b, 52c and traditional land-line communications devices.
The RNC 92a in the RAN 54 may also be connected to the SGSN 98 in the core network 806 via an IuPS interface. The SGSN 98 may be connected to the GGSN 99. The SGSN 98 and the GGSN 99 may provide the WTRUs 52a, 52b, 52c with access to packet-switched networks, such as the Internet 60, to facilitate communications between and the WTRUs 52a, 52b, 52c and IP-enabled devices.
As noted above, the core network 56 may also be connected to the networks 62, which may include other wired or wireless networks that are owned and/or operated by other service providers.
Although features and elements are described above in particular combinations, each feature or element can be used alone or in any combination with the other features and elements. Additionally, the embodiments described herein are provided for exemplary purposes only. Furthermore, the embodiments described herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (transmitted over wired or wireless connections) and computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software may be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.
This application claims the benefit of U.S. Provisional Patent Application Ser. No. 62/096,974 filed Dec. 26, 2014 and U.S. Provisional Patent Application Ser. No. 62/102,892 filed Jan. 13, 2015, the disclosures of each of which are hereby incorporated by reference as if set forth in their respective entireties herein.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US2015/000429 | 12/23/2015 | WO | 00 |
| Number | Date | Country | |
|---|---|---|---|
| 62096974 | Dec 2014 | US | |
| 62102892 | Jan 2015 | US |
