Your Step-Up Authentication Compass… NIST & SMS – Finding North – Part 2

Authored by Greg Dicovitsky, Principal Solutions Architect, RSA

In its recent solicitation for comment regarding its latest recommendation, the National Institute of Standards and Technology (NIST) has informed the public of its intent to eventually discontinue its recommending the use of Out-of-Band (OOB) Short Message Service (SMS) technologies to support the authentication of e-Commerce applications. [1]

NIST is commendably straightforward in asking for the public to comment on its guidance and giving US commercial entities time to address its issues. Motivated by its mission to promote the U.S. economy by providing technical leadership for the U.S. measurements and standards infrastructure,[2] this preliminary draft guidance is in response to their observations of emerging risks of interception and redirection of Short Message Service messages and voice calls.  NIST explicitly states that such guidance is provided for U.S. private sector entities for their use on a voluntary basis.[3]

Potential Impact

Currently, the NIST recommends solutions like those shown in the figure below. In this diagram, users can access a consumer portal, usually via a browser, and can use technologies such as OTP over SMS, Mobile Biometrics, and SecurID tokens to perform step-up-up authentication.  Through existing interfaces, RSA Adaptive Authentication can use OOB SMS to perform such step-up authentication.  In addition, the RSA Mobile SDK provides customer mobile applications with both biometric authentication and transaction signing capabilities.  At their discretion, customers may implement their own authentication workflows and blend them with Adaptive Authentication.

Figure 1: Sample Solutions For NIST Today

In a post-SMS future, the SMS functionality will disappear. (See figure 2, below.) This paradigm will use mobile applications with mobile alerts.  NIST is recommending specifications for keys on each device.  NIST considers the management of such keys to be of importance.  For the institutions that use SecurID, it will continue to remain a valid authentication mechanism.   The RSA Mobile SDK will continue to have a role, although implementations written around it will benefit from implementing its transaction signing features for step-up authentication of financial operations.  In addition, the NIST recommends the use of Transport Layer Security (TLS) for data communications with applications.

Figure 2:  A View of the Post-SMS Future

Recommendations

RSA recommends that its customers remain cognizant of their responsibilities to their stakeholders and make the appropriate recommendations to their stakeholders, public or private. Customers need not act immediately as the NIST guidance is not yet final; NIST is providing time and flexibility for U.S. commercial enterprises to voice their opinions choose their strategies and adapt.  NIST, in turn, has provided guidance on approaches that will meet its approval.

In pursuing a strategy, enterprises should note the following:

• The NIST guidance is preliminary, and is undergoing a public comment stage.   NIST has specifically used the term “deprecated” when describing its view of OOB SMS. Furthermore, NIST has specifically defined the term “deprecated”[4] to describe that OOB SMS is currently acceptable, but their support of it will be limited. (An interesting observation is how the NIST definition naturally aligns with the definition of “deprecation” in computing languages, such as Java™.[5])
• Not surprisingly, SMS providers are voicing their opposition.[6]

Examples of a Post SMS World

NIST does provide guidance on what it would prefer over time. The following are examples that meet their specifications of having a data push or alert to a secure Mobile Application using a wireless data connection, where the verifier does not store a key that identifies the device. [7]  While there are many ways to implement the guidance provided, a small subset of examples of such implementations are below:

• An e-Commerce portal directs a challenge in response to the analysis of a transaction. The portal sends a One-Time-Password (OTP) alert via a data channel to the client.  The user clicks on the alert, and it brings up an entry for the password. The client, using a secure private key in an asymmetric model (such as that of the RSA algorithm[8],) submits the one time password and digitally signs it, providing the corresponding public key. The client application sends the digitally signed OTP to the e-Commerce portal. The portal can validate that it’s the user’s public key, and that the client application signed the OTP with the user’s corresponding private key. In this case, the mobile application is the authenticator. Its private key identifies the device, its private key is not sent to the e-Commerce application. The signature validation using the public key is the evidence that the device maps to the user. There is value in the e-Commerce application tracking the public key for historical purposes in assessing the risk of a transaction. This does not violate the NIST guidance, as it is the corresponding private key that identifies the device.
• An e-Commerce portal displays an OTP to its user and tells the user to launch its mobile application and enter the OTP. The mobile application then sends the signed OTP to the e-Commerce application as above.
• An e-Commerce portal displays an OTP to its user and tells the user to wait for an alert on the user’s mobile device. The mobile device receives a data alert, and the user clicks on it. The user enters the facts that he or she received the same OTP from the application and approves the result.  The mobile application then sends a digitally signed message as above to complete the transaction.

The NIST guidance does not pre-empt the use of stronger authentication technologies.

• Unsurprisingly, NIST continues to approve of RSA SecurID tokens for such authentication. [9] In addition to hard tokens, NIST continue to approve of RSA SecurID soft tokens.[10]
• NIST also approves of biometrics for step-up authentication, such as the RSA Mobile SDK support for eye-print and fingerprint technology are supported. [11] NIST does recommend the use of such technology with another authentication factor, e.g., something you have, such as a private key secured on the device.
• NIST does recommend using SSL/TLS for push notifications and their corresponding responses.

Until NIST finalizes its recommendations, there is risk, however small, in immediately acting upon its draft guidance. It is conceivable that such guidance could change as a result of public input.

Wrapping Up

RSA recommends that its customers wait until the final guidance comes from NIST. Each customer should determine their relationship to the NIST standards, whether it is voluntary or mandated, and plan their response according to their needs and the final guidance.

Interested in joining the conversation and learning more?  Join us on October 11th at 11am ET as we explore the NIST guidance further during a live webcast – register here.

[1] https://pages.nist.gov/800-63-3/sp800-63b.html, section 5.1.3.2

[2] https://pages.nist.gov/800-63-3/sp800-63-3.html

[3] ibid.

[4] http://nstic.blogs.govdelivery.com/2016/07/29/questionsand-buzz-surrounding-draft-nist-special-publication-800-63-3/

[5] http://docs.oracle.com/javase/7/docs/technotes/guides/javadoc/deprecation/deprecation.html

[6] https://www.telesign.com/blog/post/support-2fa-nists-recommendation-step-wrong-direction/

[7] https://pages.nist.gov/800-63-3/sp800-63b.html, section 5.1.3.2

[8] http://csrc.nist.gov/nissc/2000/proceedings/papers/905slide.pdf, http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=4405829.PN.&OS=PN/4405829&RS=PN/4405829 , for historical purposes, an image of the first public description of the algorithm is here: http://www.kramerlawgroup.com/rsa.jpg

[9] https://pages.nist.gov/800-63-3/sp800-63b.html, sections 5.1.4, 5.1.5,

[10] https://pages.nist.gov/800-63-3/sp800-63b.html, section 5.1.7

[11] https://pages.nist.gov/800-63-3/sp800-63b.html, section 5.2.3; NIST also provides specifications for the effectiveness of the biometric authentication and the number of retries allowed in this section.

The post Your Step-Up Authentication Compass… NIST & SMS – Finding North – Part 2 appeared first on Speaking of Security - The RSA Blog.