Difference between revisions of "Credential"

From MgmtWiki
Jump to: navigation, search
(Solutions)
(Solutions)
(18 intermediate revisions by the same user not shown)
Line 4: Line 4:
 
==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 [[Identity Token]] which can include anti-replay elements, that (with [[User Consent]]) is sent to a requester.
+
*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==
 
==Problems==
* The only truly secure [[Credential]] is one with a secret that the [[Subject]] owns and controls.
+
* 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 simple be the source of some [[Authentication]] response that is secure from spoofing and replay.
+
* 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 [[X.509 Certificate|Certificate]] binds a credential to an [[Identifier]] of its [[Subject]] as well as (potentially) other [[Attribute]]s.
 
*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.
 
* 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.
  
 +
==References==
 
[[Category:Glossary]]
 
[[Category:Glossary]]
 
[[Category:Authentication]]
 
[[Category:Authentication]]
 
[[Category:Identity]]
 
[[Category:Identity]]
 +
[[Category:Recovery]]

Revision as of 20:19, 8 July 2020

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.

  1. /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.)
  2. /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.)
  3. /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.
  4. /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:
  1. At home recovery using another computer as either active (able to use the creds) or passive (just a store.)
  2. 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.

References