Deprecating OOB using SMS

[mschleiff]

Organization: 2

Reference (Include section and paragraph number): 5.1.3.2 second paragraph

Comment (Include rationale for comment): We really want to improve on the assurance level of single-factor passwords; I believe deprecating OOB SMS could invalidate what might be the most successful improvement over simple passwords to date. Or, perhaps more likely, could be viewed by many as a flaw in 800-63B. Of course authentication with memorized secret plus OOB SMS will have higher assurance than authentication based on memorized secret alone, but by deprecating OOB SMS, AAL would have no way to indicate any additional benefit provided by OOB SMS.

Suggested Change: Expand AAL to 4 levels; change level 3 to 4, change level 2 to 3, and make a new level 2 to include OOB SMS (without deprecation) and MFSCA (because as SES-SSE commented, “MFSCA is the only multi-factor authenticator that can be totally compromised on the host from which a transaction is initiated”).

---

Organization: 1 = Federal, 2 = Industry, 3 = Other

[mschleiff]

The OOB SMS in the proposed new Level 2 would need to be combined with memorized secret.

[mschleiff]

Comment – DFARS requirements for compliance with the 109 security controls listed in NIST SP 800-171 are driving rapid and broad deployment of multi-factor authentication in my industry. Although SP 800-171 does not specifically mention SMS, the FAQ at http://www.acq.osd.mil/dpap/pdi/docs/FAQs_Network_Penetration_Reporting_and_Contracting_for_Cloud_Services.pdf includes the following Q & A, which weakly implies that SMS (“PIN sent via a text message”) constitutes valid multifactor authentication. Q: Security requirement 3.5.3 ‐ Use multifactor authentication for local and network access to privileged accounts and for network access to non‐privileged accounts. What is meant by multifactor authentication?” A: Multifactor authentication to an information system uses two or more methods of authentication involving something you know (e.g., password); something you have (e.g., a One‐Time Password generating device like a fob, smart‐card, or a mobile app on a smartphone); and something you are (e.g., a biometric like a fingerprint or iris). The traditional authentication method uses a single factor, typically a password, while multifactor authentication requires that a second factor also be used such as PIN sent via a text message (using something you have – the cell phone) or something you are (fingerprint)).

Would deprecation of OOB SMS make this mechanism unacceptable for compliance with SP 800-171? This would significantly (and negatively) impact my organization's efforts to comply with SP 800-171. Please do not deprecate SMS + password, even if you do assign it a lower assurance level than other multi-factor mechanisms.

[paul-grassi]

Thank you for this comment. Unfortunately, SMS as a factor (even combined as a 2nd factor) is vulnerable to too many threats. Therefore, it will remain deprecated in this version. See also issue #19 for more details in regards to our disposition on this comment.

[mschleiff]

Hi Paul,

Please let me know if you receive this response.

As a service provider I recognize vulnerabilities with OOB-SMS. I also recognize vulnerabilities with other proof of possession methods. I agree that OOB-SMS has more vulnerabilities than some other forms, and should not have the same AAL as the other forms.

However, as a service provider / relying party, I am more assured of the identity of a user authenticated with OOB-SMS plus password than a user authenticated with password alone. So, I’ll probably consider password + OOB-SMS to have AAL 1.5. I’ll allow the IdPs with whom we’re federated to include LOA indicator of AAL 1.5 to my RP.

Also, as a relying party, I don’t like Multi-Factor Software Cryptographic Authenticators as much as other AAL 2 methods. I wish I could somehow recognize MFSCA inbound assertions based on MFCSA as worthy of lower confidence than inbound assertions based on other AAL 2 methods. I haven’t figure out how to do this yet.

Marty.Schleiff@boeing.commailto:Marty.Schleiff@boeing.com Associate Technical Fellow; CISSP Chief Architect: Identity & Access Management Commercial Aviation Services - IT (206) 679-5933

From: pgrassi-nist [mailto:notifications@github.com] Sent: Saturday, June 04, 2016 2:55 PM To: usnistgov/800-63-3 800-63-3@noreply.github.com Cc: Schleiff, Marty marty.schleiff@boeing.com; Author author@noreply.github.com Subject: Re: [usnistgov/800-63-3] Deprecating OOB using SMS (#71)

Thank you for this comment. Unfortunately, SMS as a factor (even combined as a 2nd factor) is vulnerable to too many threats. Therefore, it will remain deprecated in this version. See also issue #19https://github.com/usnistgov/800-63-3/issues/19 for more details in regards to our disposition on this comment.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/usnistgov/800-63-3/issues/71#issuecomment-223780389, or mute the threadhttps://github.com/notifications/unsubscribe/AScJXpkajhcKfapKH-IetiZPVOHsk3FUks5qIfRCgaJpZM4IuMsp.

[paul-grassi]

@mschleiff your message has been received. Deprecated only means 'we may remove', but for now it remains allowed. Can't you obtain the auth type from SAML or OIDC acr claim?

Anyway, I really appreciate your comments. Keep em coming. While a document that pertains to fed agencies only, we are trying very hard to remain in line with industry, so your comments are under consideration.

[mschleiff]

Passwords are vulnerable to too many threats, so by your logic (Paul), passwords should be deprecated. Software OTB authenticators and browser certificates don't do a great job of protecting secrets or private keys, making them vulnerable to many threats. So, they to should be deprecated. Or, better yet, all of these authenticators should just be assigned an appropriate assurance level.

[paul-grassi]

OOB authenticators are allowed at AAL1. They remain deprecated at all AALs however.