8.2.4 is difficult to verify

[jmanico]

8.2.4 Verify that adaptive security controls based on a consumer's environmental and contextual attributes (such as time of day, location, IP address, or device) are implemented for authentication and authorization decisions, as defined in the application's documentation. These controls must be applied when the consumer tries to start a new session and also during an existing session.

Per #3048 I think using IP for auth is a bad idea.

[elarlang]

I re-use my comment from #3048 (comment)

https://pages.nist.gov/800-63-4/sp800-63a.html

Section: https://pages.nist.gov/800-63-4/sp800-63a.html#csp-fraud-management

6. CSPs SHOULD implement - but are not limited to - the following fraud checks for their identity proofing processes based on their available identity proofing types, selected technologies, evidence, and user base:

• Transaction Analytics – Evaluate anticipated transaction characteristics – such as IP Addresses, geolocations, and transaction velocities – ...

---

https://pages.nist.gov/800-63-4/sp800-63b.html

Section: https://pages.nist.gov/800-63-4/sp800-63b.html#AAL_SEC4

At all AALs, pre-authentication checks MAY be used to lower the risk of misauthentication. For example, authentication from an unexpected geolocation or IP address block (e.g., a cloud service) might prompt the use of additional risk-based controls.

Section: https://pages.nist.gov/800-63-4/sp800-63b.html#throttle

Additional techniques MAY be used to reduce the likelihood that an attacker will lock the legitimate claimant out due to rate limiting. These include:

• Accepting only authentication requests from IP addresses from which the subscriber has been successfully authenticated before
• Leveraging other risk-based or adaptive authentication techniques to identify user behavior that falls within or outside typical norms (e.g., the use of the claimant’s IP address, geolocation, timing of request patterns, or browser metadata)

Section: https://pages.nist.gov/800-63-4/sp800-63b.html#binding

The record created by the CSP SHALL contain the date and time of significant authenticator life cycle events (e.g., binding to the subscriber account, renewal, update, expiration). The record SHOULD include information about the source of the binding (e.g., IP address, device identifier) of any device associated with the event.

---

So my proposal is - in case we want to have this requirement, then the IP address fits there and is correct to track it. The "IP address" in the requirement is not the only parameter for authentication or authorization decisions or anything else that is against zero-trust, it is just an extra parameter to follow and monitor.

[jmanico]

What I am citing in NIST 800-63b is:

1. Section 5.1.1.2

“Information such as IP addresses, email addresses, or telephone numbers that can be easily spoofed SHALL NOT be used to determine the binding of authenticators or to validate addresses of record.”

And the requirement starts with:

8.2.4 Verify that adaptive security controls based on a consumer's environmental and contextual attributes (such as time of day, location, IP address, or device) are implemented for authentication and authorization decisions...

Which is literally a direct violation of what NIST is suggestion and I think the wording of the requirement does not match the intention you are stating, Elar. I suggest a word change to clarify that.

[elarlang]

Are you talking about requirement 6.8.1 then?

6.8.1 Verify that, if the application supports multiple identity providers (IdPs), the user's identity cannot be spoofed via another supported identity provider (eg. by using the same user identifier). The standard mitigation would be for the application to register and identify the user using a combination of the IdP ID (serving as a namespace) and the user's ID in the IdP.

[elarlang]

You claim, that it comes from NIST 800-63B:

• https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver - version 3, there is no quoted text in the document and nothing about it in this section
• https://pages.nist.gov/800-63-4/sp800-63b.html - version 4 (draft), there is no quoted text and no section 5.1.1.2.

Can you provide a link, from where you copy it?

Have you read all other mentions about IP addresses from the NIST 800-63B?

[jmanico]

You're right, that was a bad quote. This came from an earlier draft of the identity proofing part of NIST 800-63-A Revision 3 (early draft).

So back the the latest version of 800-63A.

Section 4.4.1.6 (Address Confirmation) of 800-63A removed the IP address quote and simply states:

4.4.1.6 Address Confirmation:

1. Valid records to confirm address SHALL be issuing source(s) or authoritative source(s).
2. The CSP SHALL confirm address of record. The CSP SHOULD confirm address of record through validation of the address contained on any supplied, valid piece of identity evidence. The CSP MAY confirm address of record by validating information supplied by the applicant that is not contained on any supplied piece of identity evidence

There’s no mention of IP, email, or phone as invalid inputs - it’s does not take a stand (any more) about which communication mechanisms are strong/weak.

But NIST broadly requires resistance to spoofing, impersonation, and man-in-the-middle attacks across 800-63A and 800-63B. Under that criteria, IP addresses are implicitly inadequate, but not explicitly banned.

[jmanico]

So all I want to suggest is that we clarify the danger of IP for Auth.

Perhaps:

Verify that adaptive security controls based on a consumer's environmental and contextual attributes (such as time of day, location, IP address, or device) are implemented for authentication and authorization decisions, as defined in the application's documentation. These controls must be applied when the consumer tries to start a new session and also during an existing session. Please note that you should not use an IP address as a sole factor for identity or authorization.

[elarlang]

You're right, that was a bad quote. This came from an earlier draft of the identity proofing part of NIST 800-63-A Revision 3 (early draft).

As we had a similar situation just weeks ago, it sounds... quite bad.

My main point stands - 8.2.4 uses IP address just as an extra parameter to "fingerprint" the user, as the "environmental and contextual attributes" state. It does not allow any auth* decision based only on IP address. So I can not see the problem to solve here.

The message behind the "bad quote" that was talking about spoofing was for identifying the user, and for that ,we have a separate requirement 6.8.1 that I already quoted before: #3071 (comment)

Proposal from me is no action to take.

[jmanico]

First of all you were very correct when it comes to current NIST documentation. I am on vacation using my cell phone and I'll be more careful with citations as I have in other comments.

But I am not ready to close this issue. My concern is fair and still stands. I still want this requirement clarified. The requirement by my read still implies that IP is acceptable for Auth, rate limiting or logging correlation - which is all problematic - and I want to add clarification to this requirement.

Let me explain why.

I used to work for an Internet portal that had over 70 million unique user a month. I was tasked as a security engineer to build a security layer that would block IP addresses when we were getting hit by brute force and other obvious attacks.

We found out two things. (1) Sometimes we would start blocking IP addresses when a threat agent was using a dynamic IP service and we would block a large range of IP addresses for no good reason. (2) we would sometimes block IP addresses that would block many thousands of users from a company or in one case we actually blocked many millions of users from an entire country just by blocking a few IP addresses. (3) We could not rely on IP addresses for log correlation, rate limiting and similar unless we researched the source of the IP addresses first which was non-trivial.

It's this very memorable experience why I get concerned about using an IP address for various security activities. You need to research where that IP address is coming from to see if it's from a consumer IP address range, or is it from a business, or is it from internet provider with dynamic outbound IP addresses or is it from some country-wide firewall and to do so is non-trivial.

[elarlang]

Although I already quote it, requirement 8.2.4 is matching with NIST statement:

https://pages.nist.gov/800-63-4/sp800-63b.html#AAL_SEC4

At all AALs, pre-authentication checks MAY be used to lower the risk of misauthentication. For example, authentication from an unexpected geolocation or IP address block (e.g., a cloud service) might prompt the use of additional risk-based controls.