Difference between revisions of "Credential"
From MgmtWiki
(→Context) |
(→Recovery by Replacement) |
||
| (30 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
==Full Title or Meme== | ==Full Title or Meme== | ||
| − | A Credential in the digital realm is a structure which contains, at a minimum, a secret value. | + | A [[Credential]] in the digital realm is a structure which contains, at a minimum, a secret value which can be used in [[Authentication]] of a [[Subject]]. |
==Context== | ==Context== | ||
*The original digital [[Credential]] was just a shared secret, usually called a [[Password]]. | *The original digital [[Credential]] was just a shared secret, usually called a [[Password]]. | ||
| − | *More secure [[Credential]]s keep private keys which are used to build an [[ | + | *More secure [[Credential]]s keep private keys which are used to build an [[ID Token]] which can include anti-replay elements, that (with [[User Consent]]) is sent to a requester. |
| + | |||
| + | ==Problems== | ||
| + | * The only truly secure digital [[Credential]] is one with a secret that the [[Subject]] owns and controls. | ||
| + | * The secret in the credential cannot be shared in any know scalable secure manner, so it must simply be the source of some [[Authentication]] response that is secure from spoofing and replay. | ||
| + | * If a credential is used to acquire access to a critical resource, like a patients financial or health assets, some method for recovery of that access must be available. The recovery could be restoration of the credential if it has not be compromised, and placement of the credential if it has. | ||
| + | ===RFC 4949 Definition=== | ||
| + | The following taken from RFC 4949 (2007-08) gives some history and some challenges around the use of the word [[Credential]]. | ||
| + | # /authentication/ "identifier credential": A data object that is a portable representation of the association between an identifier and a unit of authentication information, and that can be presented for use in verifying an identity claimed by an entity that attempts to access a system. Example: X.509 public-key certificate. (See: anonymous credential.) | ||
| + | # /access control/ "authorization credential": A data object that is a portable representation of the association between an identifier and one or more access authorizations, and that can be presented for use in verifying those authorizations for an entity that attempts such access. Example: X.509 attribute certificate. (See: capability token, ticket.) | ||
| + | # /OSIRM/ "Data that is transferred to establish the claimed identity of an entity." [I7498-2] '''Deprecated Definition''': IDOCs SHOULD NOT use this definition. As explained in the tutorial below, an authentication process can involve the transfer of multiple data objects, and not all of those are credentials. | ||
| + | # /U.S. Government/ "An object that is verified when presented to the verifier in an authentication transaction." '''Deprecated Definition''': IDOCs SHOULD NOT use this definition, it mixes concepts in a potentially misleading way. For example, in an authentication process, it is the identity that is "verified", not the credential; the credential is "validated". (See: validate vs. verify.) | ||
| + | |||
| + | Tutorial: In general English, "credentials" are evidence or | ||
| + | testimonials that (a) support a claim of identity or authorization | ||
| + | and (b) usually are intended to be used more than once (i.e., a | ||
| + | credential's life is long compared to the time needed for one | ||
| + | use). Some examples are a policeman's badge, an automobile | ||
| + | driver's license, and a national passport. An authentication or | ||
| + | access control process that uses a badge, license, or passport is | ||
| + | outwardly simple: the holder just shows the thing. | ||
| + | |||
| + | The problem with adopting this term in Internet security is that | ||
| + | an automated process for authentication or access control usually | ||
| + | requires multiple steps using multiple data objects, and it might | ||
| + | not be immediately obvious which of those objects should get the | ||
| + | name "credential". | ||
| + | |||
| + | For example, if the verification step in a user authentication | ||
| + | process employs public-key technology, then the process involves | ||
| + | at least three data items: (a) the user's private key, (b) a | ||
| + | signed value -- signed with that private key and passed to the | ||
| + | system, perhaps in response to a challenge from the system -- and | ||
| + | (c) the user's public-key certificate, which is validated by the | ||
| + | system and provides the public key needed to verify the signature. | ||
| + | - Private key: The private key is *not* a credential, because it | ||
| + | is never transferred or presented. Instead, the private key is | ||
| + | "authentication information", which is associated with the | ||
| + | user's identifier for a specified period of time and can be | ||
| + | used in multiple authentications during that time. | ||
| + | - Signed value: The signed value is *not* a credential; the | ||
| + | signed value is only ephemeral, not long lasting. The OSIRM | ||
| + | definition could be interpreted to call the signed value a | ||
| + | credential, but that would conflict with general English. | ||
| + | - Certificate: The user's certificate *is* a credential. It can | ||
| + | be "transferred" or "presented" to any person or process that | ||
| + | needs it at any time. A public-key certificate may be used as | ||
| + | an "identity credential", and an attribute certificate may be | ||
| + | used as an "authorization credential". | ||
| + | This wiki does not accept the concept that the user's certificate is a credential and neither do any [[Identifier or Attribute Provider]]s. Since the certificate is a public document anyone could have a copy and the [[Presentation]] of a copy is not in any way proof of anything. | ||
| + | |||
==Solutions== | ==Solutions== | ||
| − | *A Certificate binds a credential to an [[Identifier]] of its | + | *A [[X.509 Certificate|Certificate]] binds a credential to an [[Identifier]] of its [[Subject]] as well as (potentially) other [[Attribute]]s. |
| + | * Often there is also a binding to some sort of real-world credential, typically a piece of paper with a seal. | ||
| + | * NIST 800-63 (all versions) describe a [[Credential Service Provider]] which is designed to issue credentials to users after they by had the [[Identity Proofing]] prior to employment by the government. This flow can be substantially different in commercial systems, but there is always a need to verify the security of the user's private key or other secret that is a part of a credential. | ||
| + | * [[Web Authentication]] defines a Public Key Credential as data one entity presents to another in order to authenticate the former to the latter [RFC4949]. The term public key credential refers to one of: a public key credential source, the possibly-attested credential public key corresponding to a public key credential source, or an authentication assertion. Which one is generally determined by context. In other words, this credential is evidence that the user holds the private key, while in rfc 4949 and in this wiki, the credential is the object held that can be used multiple times (i.e. the private key). | ||
| + | * The best known [[Credential]] of the day (2020) is a [[Private Key Component]]. | ||
| + | |||
| + | ===Recovery by Restoration=== | ||
| + | * In the simplistic case of a password, the only restoration would be a copy of the password stored by the [[Subject]] in some secure location. | ||
| + | * In the case of a private key in a secure store, it may be sufficient to restore the value to a secure store if the user has had the foresight to enable such a process. These are never simple and always involve a second factor or physical access to the secure store as well. Two possible approaches: | ||
| + | # At home recovery using another computer as either active (able to use the creds) or passive (just a store.) | ||
| + | # In the cloud, either on a share belonging to the subject, or in a trusted third party. In either case the creds might be encrypted in such a manner that only the user could access them for installation in a smartphone. | ||
| + | |||
| + | ===Recovery by Replacement=== | ||
| + | * In the simplistic case of a password as a credential, a [[Website]] will go through a password replacement process which typically includes some other factor of identification, such as a cell phone or email address. | ||
| + | * In the case of a private key in a secure store, it may be sufficient to create a new value in a secure store. The recovery process is them much like the initial creation of the credential and the roll out of the certificate for that new key to all of the places where it will be used. | ||
| + | * A hybrid solution would create a new key on the subject's device and then use it to encrypt the incoming key so that only the user's device could decrypt it and load it into the device's secure store. | ||
| + | |||
| + | ===Browser Credential Management=== | ||
| + | The W3C Is maintaining an API to let user's store credential in the browser. See the wiki page [[Credential Management]] for current information about that. | ||
| + | |||
| + | ==References== | ||
[[Category:Glossary]] | [[Category:Glossary]] | ||
| + | [[Category:Authentication]] | ||
| + | [[Category:Identity]] | ||
| + | [[Category:Recovery]] | ||
Revision as of 19:49, 19 February 2021
Contents
Full Title or Meme
A Credential in the digital realm is a structure which contains, at a minimum, a secret value which can be used in Authentication of a Subject.
Context
- The original digital Credential was just a shared secret, usually called a Password.
- More secure Credentials keep private keys which are used to build an ID Token which can include anti-replay elements, that (with User Consent) is sent to a requester.
Problems
- The only truly secure digital Credential is one with a secret that the Subject owns and controls.
- The secret in the credential cannot be shared in any know scalable secure manner, so it must simply be the source of some Authentication response that is secure from spoofing and replay.
- If a credential is used to acquire access to a critical resource, like a patients financial or health assets, some method for recovery of that access must be available. The recovery could be restoration of the credential if it has not be compromised, and placement of the credential if it has.
RFC 4949 Definition
The following taken from RFC 4949 (2007-08) gives some history and some challenges around the use of the word Credential.
- /authentication/ "identifier credential": A data object that is a portable representation of the association between an identifier and a unit of authentication information, and that can be presented for use in verifying an identity claimed by an entity that attempts to access a system. Example: X.509 public-key certificate. (See: anonymous credential.)
- /access control/ "authorization credential": A data object that is a portable representation of the association between an identifier and one or more access authorizations, and that can be presented for use in verifying those authorizations for an entity that attempts such access. Example: X.509 attribute certificate. (See: capability token, ticket.)
- /OSIRM/ "Data that is transferred to establish the claimed identity of an entity." [I7498-2] Deprecated Definition: IDOCs SHOULD NOT use this definition. As explained in the tutorial below, an authentication process can involve the transfer of multiple data objects, and not all of those are credentials.
- /U.S. Government/ "An object that is verified when presented to the verifier in an authentication transaction." Deprecated Definition: IDOCs SHOULD NOT use this definition, it mixes concepts in a potentially misleading way. For example, in an authentication process, it is the identity that is "verified", not the credential; the credential is "validated". (See: validate vs. verify.)
Tutorial: In general English, "credentials" are evidence or
testimonials that (a) support a claim of identity or authorization
and (b) usually are intended to be used more than once (i.e., a
credential's life is long compared to the time needed for one
use). Some examples are a policeman's badge, an automobile
driver's license, and a national passport. An authentication or
access control process that uses a badge, license, or passport is
outwardly simple: the holder just shows the thing.
The problem with adopting this term in Internet security is that
an automated process for authentication or access control usually
requires multiple steps using multiple data objects, and it might
not be immediately obvious which of those objects should get the
name "credential".
For example, if the verification step in a user authentication
process employs public-key technology, then the process involves
at least three data items: (a) the user's private key, (b) a
signed value -- signed with that private key and passed to the
system, perhaps in response to a challenge from the system -- and
(c) the user's public-key certificate, which is validated by the
system and provides the public key needed to verify the signature.
- Private key: The private key is *not* a credential, because it
is never transferred or presented. Instead, the private key is
"authentication information", which is associated with the
user's identifier for a specified period of time and can be
used in multiple authentications during that time.
- Signed value: The signed value is *not* a credential; the
signed value is only ephemeral, not long lasting. The OSIRM
definition could be interpreted to call the signed value a
credential, but that would conflict with general English.
- Certificate: The user's certificate *is* a credential. It can
be "transferred" or "presented" to any person or process that
needs it at any time. A public-key certificate may be used as
an "identity credential", and an attribute certificate may be
used as an "authorization credential".
This wiki does not accept the concept that the user's certificate is a credential and neither do any Identifier or Attribute Providers. Since the certificate is a public document anyone could have a copy and the Presentation of a copy is not in any way proof of anything.
Solutions
- A Certificate binds a credential to an Identifier of its Subject as well as (potentially) other Attributes.
- Often there is also a binding to some sort of real-world credential, typically a piece of paper with a seal.
- NIST 800-63 (all versions) describe a Credential Service Provider which is designed to issue credentials to users after they by had the Identity Proofing prior to employment by the government. This flow can be substantially different in commercial systems, but there is always a need to verify the security of the user's private key or other secret that is a part of a credential.
- Web Authentication defines a Public Key Credential as data one entity presents to another in order to authenticate the former to the latter [RFC4949]. The term public key credential refers to one of: a public key credential source, the possibly-attested credential public key corresponding to a public key credential source, or an authentication assertion. Which one is generally determined by context. In other words, this credential is evidence that the user holds the private key, while in rfc 4949 and in this wiki, the credential is the object held that can be used multiple times (i.e. the private key).
- The best known Credential of the day (2020) is a Private Key Component.
Recovery by Restoration
- In the simplistic case of a password, the only restoration would be a copy of the password stored by the Subject in some secure location.
- In the case of a private key in a secure store, it may be sufficient to restore the value to a secure store if the user has had the foresight to enable such a process. These are never simple and always involve a second factor or physical access to the secure store as well. Two possible approaches:
- At home recovery using another computer as either active (able to use the creds) or passive (just a store.)
- In the cloud, either on a share belonging to the subject, or in a trusted third party. In either case the creds might be encrypted in such a manner that only the user could access them for installation in a smartphone.
Recovery by Replacement
- In the simplistic case of a password as a credential, a Website will go through a password replacement process which typically includes some other factor of identification, such as a cell phone or email address.
- In the case of a private key in a secure store, it may be sufficient to create a new value in a secure store. The recovery process is them much like the initial creation of the credential and the roll out of the certificate for that new key to all of the places where it will be used.
- A hybrid solution would create a new key on the subject's device and then use it to encrypt the incoming key so that only the user's device could decrypt it and load it into the device's secure store.
Browser Credential Management
The W3C Is maintaining an API to let user's store credential in the browser. See the wiki page Credential Management for current information about that.
