search

IDPros / bok

This is a public comment environment for the IDPro body of knowledge.
68 stars 26 forks source link

Definition of authentication factors #78

Open davidwilliam opened 2 years ago

davidwilliam commented 2 years ago

I am new here so my apologies if the following has been already discussed.

I could not find a definition of authentication factor in the Terminology in the IDPro Body of Knowledge.

The reason I find this relevant is due to an apparent inconsistency between what seems to be different notions associated with authentication factors and authenticators.

On NIST SP 800-63-3, in Section 4.3.1, we have:

The classic paradigm for authentication systems identifies three factors as the cornerstones of authentication:

According to the above, “something you know”, “something you have”, and “something you are” are factors, the cornerstones of authentication in the classic paradigm for authentication systems. By this notion, I would understand that there are multiple authenticators associated to each factor, or, using software engineering language, one factor has many authenticators.

In the same section, we read:

Authentication factors classified as something you know are not necessarily secrets, either.

Now, authentication factors are described as items that can be classified. In the particular instance above, there are authentication factors classified as “something you know”. Therefore, “something you know”, “something you have”, and “something you are” would be classifications/categories of factors, and not actual factors. So this seems to conflict with the previous notion. That is, it seems that “something you know”, “something you have”, and “something you are” are classifications of factors and “password”, “ID badge”, “fingerprint” would be actual factors. By this notion, I would understand that there are multiple factors associated with each classification, or, one classification has many factors.

The BoK article https://bok.idpro.org/article/id/78/ does not directly define what a factor is. In the definition of “Multi-Factor Authentication, it says “… for a resource being accessed using more than one factor (something you know (e.g., password), something you have (e.g., smartphone), something you are (e.g., fingerprint).” So here, “something you know”, “something you have”, and “something you are” are factors.

In the same article, we read: “There are many different possible authentication factors, such as memorized secrets, hardware tokens, and biometrics. These are often referred to as “something you know,” “something you have,” and “something you are.” So now, passwords, hardware tokens, and biometrics are described as authentication factors. Moreover, it says "The most common factor is username and password."

My take would be that if "password", "hardware token", "fingerprint", etc., are all the same, then referring to them as just "factors" would suffice. However, they are different in nature and operation, and these differences are better understood when organized in categories, classifications.

Without proposing a definition to authentication factors, it seems that either saying that “something you know”, “something you have”, and “something you are” are authentication factors and their concrete instances are authenticators, or saying that “something you know”, “something you have”, and “something you are” are types of authentication factors and “password”, “ID badge”, “fingerprint” are examples actual factors, would be more consistent than how it is described now.

The closest I got to an informal definition (although not really a definition) of a factor comes from the previously mentioned fragment from NIST SP 800-63-3, in Section 4.3.1, where it says that factors are the cornerstones of authentication in the classic paradigm for authentication systems.

If I am missing something, please let me know.

GrahamWilliamson commented 2 years ago

Hi David; It seems you're focussing on the how (eminently useful) not the what. We (IAM professionals) don't have a unified definition of the term Authentication. It used to mean your network logon when you got to work each morning, that gave you access to everything on the corporate network (or at least the subnet that your department used). But then Oracle Business Suite came along and set-up its own database so it could differentiate between the CFO and an admin clerk. This was generally called Authorisation. Now when I connect to the SaaS app that provides financial administration for my company, and I get an access token that gives me write-access to the general ledger based on my fingerprint - is this an authentication? Thx. Graham

From: David William @.> Sent: Sunday, 21 November 2021 5:02 AM To: IDPros/bok @.> Cc: Subscribed @.***> Subject: [IDPros/bok] Definition of authentication factors (Issue #78)

I am new here so my apologies if the following has been already discussed.

I could not find a definition of authentication factor in the Terminology in the IDPro Body of Knowledge.

The reason I find this relevant is due to an apparent inconsistency between what seems to be different notions associated with authentication factors and authenticators.

On NIST SP 800-63-3, in Section 4.3.1, we have:

The classic paradigm for authentication systems identifies three factors as the cornerstones of authentication:

According to the above, "something you know", "something you have", and "something you are" are factors, the cornerstones of authentication in the classic paradigm for authentication systems. By this notion, I would understand that there are multiple authenticators associated to each factor, or, using software engineering language, one factor has many authenticators.

In the same section, we read:

Authentication factors classified as something you know are not necessarily secrets, either.

Now, authentication factors are described as items that can be classified. In the particular instance above, there are authentication factors classified as "something you know". Therefore, "something you know", "something you have", and "something you are" would be classifications/categories of factors, and not actual factors. So this seems to conflict with the previous notion. That is, it seems that "something you know", "something you have", and "something you are" are classifications of factors and "password", "ID badge", "fingerprint" would be actual factors. By this notion, I would understand that there are multiple factors associated with each classification, or, one classification has many factors.

The BoK article https://bok.idpro.org/article/id/78/https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbok.idpro.org%2Farticle%2Fid%2F78%2F&data=04%7C01%7C%7Cd330d13564684fd808d708d9ac58344b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637730317465601367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=P0rtvVxARtHGHze%2F%2FoqhlYDr27vfSmrPcXDTDlw8Nus%3D&reserved=0 does not directly define what a factor is. In the definition of "Multi-Factor Authentication, it says "... for a resource being accessed using more than one factor (something you know (e.g., password), something you have (e.g., smartphone), something you are (e.g., fingerprint)." So here, "something you know", "something you have", and "something you are" are factors.

In the same article, we read: "There are many different possible authentication factors, such as memorized secrets, hardware tokens, and biometrics. These are often referred to as "something you know," "something you have," and "something you are." So now, passwords, hardware tokens, and biometrics are described as authentication factors. Moreover, it says "The most common factor is username and password."

My take would be that if "password", "hardware token", "fingerprint", etc., are all the same, then referring to them as just "factors" would suffice. However, they are different in nature and operation, and these differences are better understood when organized in categories, classifications.

Without proposing a definition to authentication factors, it seems that either saying that "something you know", "something you have", and "something you are" are authentication factors and their concrete instances are authenticators, or saying that "something you know", "something you have", and "something you are" are types of authentication factors and "password", "ID badge", "fingerprint" are examples actual factors, would be more consistent than how it is described now.

The closest I got to an informal definition (although not really a definition) of a factor comes from the previously mentioned fragment from NIST SP 800-63-3, in Section 4.3.1, where it says that factors are the cornerstones of authentication in the classic paradigm for authentication systems.

If I am missing something, please let me know.

- You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FIDPros%2Fbok%2Fissues%2F78&data=04%7C01%7C%7Cd330d13564684fd808d708d9ac58344b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637730317465601367%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=hmajYnQf9RZG4WGNOim7bBm%2BJCIyVJzSveperuGTmkk%3D&reserved=0, or unsubscribehttps://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FALCHYI6AP3FISGVF5NLCXIDUM7WBXANCNFSM5IOHZWDQ&data=04%7C01%7C%7Cd330d13564684fd808d708d9ac58344b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637730317465611323%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=3yj15eBgodTtfnOTigMDhWJtYPcc4e%2FlADknJdL5hNA%3D&reserved=0. Triage notifications on the go with GitHub Mobile for iOShttps://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04%7C01%7C%7Cd330d13564684fd808d708d9ac58344b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637730317465621283%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=AOTRGqh3v7K917b6K7pzGjK6Wpjg12PY4eBzdmjVdNA%3D&reserved=0 or Androidhttps://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04%7C01%7C%7Cd330d13564684fd808d708d9ac58344b%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637730317465621283%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vaPLO6DYGNg4OTUCQUEwkbpx8OB6Us%2BB8%2BprPSsK1iA%3D&reserved=0.

davidwilliam commented 2 years ago

Hi Graham,

Thank you very much for your comments and discussion.

I have a background in theoretical computer science, so I appreciate the complexity of providing (formal) definitions.

I guess my concern is that in the same text, an authentication factor is both a category and an item that is categorized (by a type of factor) when, naturally, that could not be the case.

Concretely, my questions are: what is appropriate to say? That "what you know," "what you have," and "what you are" are classifications of authentication factors, or are they factors themselves? If they are classifications of factors, then "password," "hardware token," "fingerprint" would be examples of actual factors. If "what you know," "what you have," and "what you are" are the actual factors, then how to appropriately refer to "password," "hardware token," "fingerprint," etc.? I can't find a consistent answer to that in current texts related to IAM.

The texts I mentioned both on NIST SP 800-63-3 and BoK convey both ideas, which seem conflicting.

Thank you, David

GrahamWilliamson commented 2 years ago

Hi David; Good stuff! Multi-factor authentication is, IMHO, limited to three types (or classifications) - knowledge, possession and biometric. I did once hear a presentation that referred to location and time of day being additional 'factors' but they are simply attributes of the authentication event. Of the three, knowledge passwords are easiest - a password is a user attribute that allows a knowledge factor authentication to occur. We often refer to the password as the factor but it's not strictly true. Possession factors are a bit more difficult. If you're using an SMS'd code that you then enter into an authentication screen, the code is sometimes considered to be the factor, but again, it's is simply facilitating the possession factor authentication. If you're using an authenticator app for a possession factor authentication, the app isn't the factor - it's a tool that facilitates a possession factor authentication event. Biometric factor authentication uses a user's fingerprint template, or their visage template for facial recognition. The templates are user attributes that allow a user's identity to be confirmed via a biometric factor authentication. Hope this helps. Thx. Graham

From: David William @.> Sent: Monday, 22 November 2021 12:01 PM To: IDPros/bok @.> Cc: GrahamWilliamson @.>; Comment @.> Subject: Re: [IDPros/bok] Definition of authentication factors (Issue #78)

Hi Graham,

Thank you very much for your comments and discussion.

I have a background in theoretical computer science, so I appreciate the complexity of providing (formal) definitions.

I guess my concern is that in the same text, an authentication factor is both a category and an item that is categorized (by a type of factor) when, naturally, that could not be the case.

Concretely, my questions are: what is appropriate to say? That "what you know," "what you have," and "what you are" are classifications of authentication factors, or are they factors themselves? If they are classifications of factors, then "password," "hardware token," "fingerprint" would be examples of actual factors. If "what you know," "what you have," and "what you are" are the actual factors, then how to appropriately refer to "password," "hardware token," "fingerprint," etc.? I can't find a consistent answer to that in current texts related to IAM.

The texts I mentioned both on NIST SP 800-63-3 and BoK convey both ideas, which seem conflicting.

Thank you, David

- You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FIDPros%2Fbok%2Fissues%2F78%23issuecomment-975003102&data=04%7C01%7C%7C4474db9161be402eed3308d9ad5bf3d3%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637731432710720732%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=fcf3%2FqiZIhab9L0v4S9Cpw1NVn%2F%2FGR1jseMoxonXptw%3D&reserved=0, or unsubscribehttps://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FALCHYI6P4A6V4GZDZNEI2WLUNGP6LANCNFSM5IOHZWDQ&data=04%7C01%7C%7C4474db9161be402eed3308d9ad5bf3d3%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637731432710730687%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=tiitUJNV5X2miwm4l4EoK3ZGbX9UNcXKr1OtHybRtlo%3D&reserved=0. Triage notifications on the go with GitHub Mobile for iOShttps://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04%7C01%7C%7C4474db9161be402eed3308d9ad5bf3d3%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637731432710730687%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=R6xUa86eLcDBO3B340vVB2i0nxjcuJTI%2Bdj%2BYL%2BDWfw%3D&reserved=0 or Androidhttps://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04%7C01%7C%7C4474db9161be402eed3308d9ad5bf3d3%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637731432710740634%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=cvVPk6dqNv72NF1RSu3GJXPXif1gtGyYG%2F3dQrVHNCw%3D&reserved=0.

davidwilliam commented 2 years ago

Hi Graham,

Thank you for your very helpful comments.

I appreciate the examples you provided. It gives me a much better perspective of authentication factors.

I like describing factor types as knowledge, and possession, but when it comes to biometrics, we confine this classification to human entities. Since authentication is not just for humans, there should be an equivalent to biometrics for the particular case of non-human entities. In other words, what is "what you are" for machines? But that's a different topic.

Your comments helped a lot.

Thank you, David

teamktown commented 2 years ago

@davidwilliam, Great dive into the multiple factors story! If you are looking for the dictionary of what some factors are and how they are signalled over the wire, you may be interested in the modernization work Research and Education Federations MFA (aka REFEDS-MFA) signalling in the SAML2 AuthenticationContext Space.

This new signalling string in the SAML2 Authentication Context helps modernize the OASIS doc. Section 3.4 lists the possible single factors and adds a new curated one for REFEDS-MFA to imply multiple factors were used in the SSO sign-on and shows as a single value in the Authentication Context string in the Assertion. The original OASIS definition didn't cover the 'something you are, something you know, something you have' aspect in a single string and REFEDS-MFA does and is used by the NIH in a variety of their services and others are also following in doing so as well.

The REFEDS-MFA approach is to embody the multiple factors (minimum of two) such that no one factor can intrude/compromise the other factor. Here's the link to the REFEDS MFA Profile

Part of the work the REFEDS-MFA standard is trying to address is how to curate the changing landscape. Note that back in 2004 SMS was considered 'secure' but in 2021, SMS known to be an insecure channel. Curating this MFA definition and approach is where a lot of thinking and work is being applied to form a scalable way to signal MFA well. You can see the product of some of this work from the global community here: https://wiki.refeds.org/display/PRO/MFA+Profile+FAQ

While the specification is available and actively used by hundreds of Idp in the R&E space from the 1000's of IdPs in eduGAIN covering 73 countries it is portable to be used anywhere in SAML2 and OIDC where signalling it implies the appropriate practices were employed for that sign on.

I hope this helps as the MFA space is explored!

espenbago commented 2 years ago

Some of the confusion associated with the use of "factors" likely come from a common (lazy) way to use words in general: Using the word both to mean the actual thing itself while also meaning the "class of things" in questions; e.g.: Factors = (shorthand for) categories of factors Factors = actual factors

People might still feel that the "correct way" is to say that the categories/classes are "factors", though. (And as the discussion above shows, there are plenty of other elements confusing the matter here.)

Either we can allow both ways of looking at it, or we can decide that one is wrong and illegal to use. Though when deciding that one is wrong, some method of enforcing this "law" is necessary, and no such enforcement method exists today. (I.e. we have neither one legislative branch of the Identity & Access government nor one judicial, nor one executive branch of government today.)

As for the other elements confusing the matter (therefore worth being aware of): For the "Knowledge" class of factors, a password is no longer always actually or strictly "known" any longer. Most of my own passwords are now unknown to me (generated and never seen, at least never remembered), and stored in a vault or password manager of some kind. Theoretically I still "know" these passwords after I unlock them (using for example a hardware key), because I can (again theoretically) now memorize them. I just never do, since I use auto-fill or cut and paste and similar. A few more years of this, and passwords won't be thought of as being part of the "knowledge" class any longer, unless you're old enough to remember not having internet on your phone. They would feel more like "possession."

I think the main takeaway here is that the whole "factors" part of the "authentication" definition is not approaching solidification, but rather getting more and more fluid (and/or outdated).

There was also some discussion above about the distinction between, or parts played by, usernames, passwords and codes, and how they are supplied (channels and tools). What I didn't see there, and wanted to ask was: Is it fair to specify (when talking about the process of authentication) that there is normally an identifier (identification code, string etc), which is typically either directly a username, or a reference to one, including strings like email addresses and phone numbers. And correspondingly an authenticator, such as a password, a hardware key, a biometric fact - or a reference to one of these?

These are not my ideas, I just don't remember where I've seen them. But they have been useful to me when needing to break down the authentication process into its basic building blocks.

What additionally makes all of this frustratingly complex is that in building/coding the process of authentication (and just wait until we get to the process of authorization..), we're often using references to the original constructs, not the constructs themselves, but we still call them by same name. (I.e. using the word to mean both the thing and the reference to the thing, be it a username, password or token etc.)

This gets confusing even when trying to describe it, as here. Imagine trying to understand this mix of things and references to things, and things and classes of things, in cases where it's just expected to be understood as the author (of the code or the documentation) had in mind, but didn't clarify. The levels of abstraction are dizzying (and always poorly documented).

davidwilliam commented 2 years ago

Hi @teamktown,

Thank you very much for your comments and the great set of references. I am going over the links and finding other related material. This is very helpful.

Hi @espenbago,

Thank you for your comments and discussion. I am not sure if we should go as far as making something illegal but it would not hurt to have a recommended way.

After reading and considering everything cited in this thread, I believe a consistent description (yet lacking a definition) would be:

So the above are factors. It seems to me that saying that the above are classifications of factors would immediately imply that passwords, hardware tokens, and fingerprints, for instance, would be factors associated, each one respectively, with the classifications above.

Instead, again using software engineering language, one factor has many authenticators. So it seems more consistent to say that password is an authenticator associated with a knowledge factor.

Here is, perhaps, a compelling argument for referring to knowledge, possession, and inherence as factors and, as an example, password, hardware token, and fingerprint as authenticators:

Imagine that someone is trying to authenticate to their bank account. The bank presents a form requesting username (identity claim) and password (authenticator). The user provides that information and, if correct, the bank presents a second screen requesting answers to three questions: 1) What was the name of your first pet? 2) What is your mother's maiden name? 3) What is your favorite fruit? The user provides that information and if correct, he is successfully authenticated.

Two steps are involved in the above example. Two authenticators were used (password, secret answers). But only one factor is in place (knowledge). Thus, I assume that we cannot call the above example as multi-factor authentication.