Difference between revisions of "Assurance"

From MgmtWiki
Jump to: navigation, search
m (Solutions)
(Authenticator Assurance Level)
(8 intermediate revisions by the same user not shown)
Line 10: Line 10:
 
* [https://pages.nist.gov/800-63-3/sp800-63-3.html New version of SP 800-63-3] with [[Assurance]] separated out from the other [[Authentication]] [[Attribute]]s.
 
* [https://pages.nist.gov/800-63-3/sp800-63-3.html New version of SP 800-63-3] with [[Assurance]] separated out from the other [[Authentication]] [[Attribute]]s.
 
* [[Provenance]] is a term that is sometimes used for the level of [[Assurance]] that a [[Data Controller]] has in the origin and reliability of [[User]] [[Attribute]]s, especially health care data
 
* [[Provenance]] is a term that is sometimes used for the level of [[Assurance]] that a [[Data Controller]] has in the origin and reliability of [[User]] [[Attribute]]s, especially health care data
 +
* The [[Assurance]] level measures the quality of the [[Binding]]:
 +
** (63A-IAL)  of the subject to the [[Attribute]]s or [[Claim]]s about that subject.
 +
** (63B-AAL)  of the subject to the [[Credential]] used to verify the identity of the subject (which includes attributes from IAL)
 +
** (63C-FAL) of the subject or issuer to the [[Best_Practice_in_HealthCare#Federated_Trust_Anchor|Trust Anchor]].
  
 
For a [[User]] that wants some [[Assurance]] about a [[Web Site]] see [[Trusted Third Party]].
 
For a [[User]] that wants some [[Assurance]] about a [[Web Site]] see [[Trusted Third Party]].
Line 28: Line 32:
 
===A summary of the 3 categories now in NIST 800-63-3===
 
===A summary of the 3 categories now in NIST 800-63-3===
 
A summary of each of the identity, authenticator, and federation assurance levels is provided below.
 
A summary of each of the identity, authenticator, and federation assurance levels is provided below.
 +
 +
When described generically or bundled, NIST guidelines refers to IAL, AAL, and FAL as xAL.
  
 
====Identity Assurance Level====
 
====Identity Assurance Level====
 +
Answers the question - how do we know who the subject is in the real-world.
 
#  At IAL1, attributes, if any, are self-asserted or should be treated as self-asserted.
 
#  At IAL1, attributes, if any, are self-asserted or should be treated as self-asserted.
 
#  At IAL2, either remote or in-person identity proofing is required. IAL2 requires identifying attributes to have been verified in person or remotely using, at a minimum, the procedures given in SP 800-63A.
 
#  At IAL2, either remote or in-person identity proofing is required. IAL2 requires identifying attributes to have been verified in person or remotely using, at a minimum, the procedures given in SP 800-63A.
Line 35: Line 42:
  
 
====Authenticator Assurance Level====
 
====Authenticator Assurance Level====
 +
Answers the question - how much should we trust the information that we have been given (supposedly) by the subject.
 
# AAL1 provides some assurance that the claimant controls an authenticator registered to the subscriber. AAL1 requires single-factor authentication using a wide range of available authentication technologies. Successful a AAL1 provides some assurance that the claimant controls an authenticator registered to the subscriber. AAL1 requires single-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator(s) through a secure authentication protocol.
 
# AAL1 provides some assurance that the claimant controls an authenticator registered to the subscriber. AAL1 requires single-factor authentication using a wide range of available authentication technologies. Successful a AAL1 provides some assurance that the claimant controls an authenticator registered to the subscriber. AAL1 requires single-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator(s) through a secure authentication protocol.
 
#  AAL2 provides high confidence that the claimant controls authenticator(s) registered to the subscriber. Proof of possession and control of two different authentication factors is required through a secure authentication protocol. Approved cryptographic techniques are required at AAL2 and above.
 
#  AAL2 provides high confidence that the claimant controls authenticator(s) registered to the subscriber. Proof of possession and control of two different authentication factors is required through a secure authentication protocol. Approved cryptographic techniques are required at AAL2 and above.
#  AAL3 provides very high confidence that the claimant controls authenticator(s) registered to the subscriber. Authentication at AAL3 is based on proof of possession of a key through a cryptographic protocol. AAL3 is like AAL2 but also requires a “hard” cryptographic authenticator that provides verifier impersonation resistance.
+
#  AAL3 provides very high confidence that the claimant controls authenticator(s) registered to the subscriber. Authentication at AAL3 is based on proof of possession of a key through a cryptographic protocol. AAL3 is like AAL2 but also requires a “hard” cryptographic authenticator that provides verifier [[Impersonation]] resistance.
  
 
====Federation Assurance Level====
 
====Federation Assurance Level====
 +
Answers the question - how much should we trust the information that we have been given (supposedly) by  some federation server.
 
#  FAL1 permits the RP to receive a bearer assertion from an identity provider (IdP). The IdP must sign the assertion using approved cryptography.
 
#  FAL1 permits the RP to receive a bearer assertion from an identity provider (IdP). The IdP must sign the assertion using approved cryptography.
 
#  FAL2 adds the requirement that the assertion be encrypted using approved cryptography such that the RP is the only party that can decrypt it.
 
#  FAL2 adds the requirement that the assertion be encrypted using approved cryptography such that the RP is the only party that can decrypt it.
 
#  FAL3 requires the subscriber to present proof of possession of a cryptographic key reference to in the assertion and the assertion artifact itself. The assertion must be signed using approved cryptography and encrypted to the RP using approved cryptography.
 
#  FAL3 requires the subscriber to present proof of possession of a cryptographic key reference to in the assertion and the assertion artifact itself. The assertion must be signed using approved cryptography and encrypted to the RP using approved cryptography.
When described generically or bundled, NIST guidelines refers to IAL, AAL, and FAL as xAL.
 
  
 
===Assurance in Verticals===
 
===Assurance in Verticals===

Revision as of 13:40, 26 August 2020

Full Title or Meme

The level of trust that can be afforded a claim of an Identifier or Attribute.

Context

  • Some means for assuring the Web Site Security is required. See that page for details.
  • The rest of this page is about establishing a level of assurance for User Information about a User also known as a Subject.
  • Previous version of SP 800-63-2 described level of Assurance or LOA that are still part of ISO standards. NIST has published a FAQ to describe the reasons for the upgrade.
  • New version of SP 800-63-3 with Assurance separated out from the other Authentication Attributes.
  • Provenance is a term that is sometimes used for the level of Assurance that a Data Controller has in the origin and reliability of User Attributes, especially health care data
  • The Assurance level measures the quality of the Binding:
    • (63A-IAL) of the subject to the Attributes or Claims about that subject.
    • (63B-AAL) of the subject to the Credential used to verify the identity of the subject (which includes attributes from IAL)
    • (63C-FAL) of the subject or issuer to the Trust Anchor.

For a User that wants some Assurance about a Web Site see Trusted Third Party.

Problems

  • In contexts where names are not validated (of low Assurance) the problem arises that trolls many adopt the name of some well-known person to be able to make statements that falsely appear to be from the real person.[1]
  • See discussion on the pages for Ephemeral and Persistent.
  • Most of the existing protocols, like OpenID Connect and SAML 2.0 support the older NIST SP 800-63-2 level of assurance ratings. These are also baked into RFC 6711 "An IANA Registry for Level of Assurance (LoA) Profiles" and ISO/IEC 291151.

Solutions

A rather facile mapping of the NIST 800-63-3 levels of Assurance to the processes known today is:

  • LOA1, AAL1 ==> password
  • LOA2, AAL2 ==> 2FA (two (or more) factors of authentication).
  • LOA3, AAL3 ==> U2F

The best source of Truth about an Identity is obtained by documentation of the Identity Proofing process. That is something that can be audited to measure reality against expectations.

A summary of the 3 categories now in NIST 800-63-3

A summary of each of the identity, authenticator, and federation assurance levels is provided below.

When described generically or bundled, NIST guidelines refers to IAL, AAL, and FAL as xAL.

Identity Assurance Level

Answers the question - how do we know who the subject is in the real-world.

  1. At IAL1, attributes, if any, are self-asserted or should be treated as self-asserted.
  2. At IAL2, either remote or in-person identity proofing is required. IAL2 requires identifying attributes to have been verified in person or remotely using, at a minimum, the procedures given in SP 800-63A.
  3. At IAL3, in-person identity proofing is required. Identifying attributes must be verified by an authorized CSP representative through examination of physical documentation as described in SP 800-63A.

Authenticator Assurance Level

Answers the question - how much should we trust the information that we have been given (supposedly) by the subject.

  1. AAL1 provides some assurance that the claimant controls an authenticator registered to the subscriber. AAL1 requires single-factor authentication using a wide range of available authentication technologies. Successful a AAL1 provides some assurance that the claimant controls an authenticator registered to the subscriber. AAL1 requires single-factor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator(s) through a secure authentication protocol.
  2. AAL2 provides high confidence that the claimant controls authenticator(s) registered to the subscriber. Proof of possession and control of two different authentication factors is required through a secure authentication protocol. Approved cryptographic techniques are required at AAL2 and above.
  3. AAL3 provides very high confidence that the claimant controls authenticator(s) registered to the subscriber. Authentication at AAL3 is based on proof of possession of a key through a cryptographic protocol. AAL3 is like AAL2 but also requires a “hard” cryptographic authenticator that provides verifier Impersonation resistance.

Federation Assurance Level

Answers the question - how much should we trust the information that we have been given (supposedly) by some federation server.

  1. FAL1 permits the RP to receive a bearer assertion from an identity provider (IdP). The IdP must sign the assertion using approved cryptography.
  2. FAL2 adds the requirement that the assertion be encrypted using approved cryptography such that the RP is the only party that can decrypt it.
  3. FAL3 requires the subscriber to present proof of possession of a cryptographic key reference to in the assertion and the assertion artifact itself. The assertion must be signed using approved cryptography and encrypted to the RP using approved cryptography.

Assurance in Verticals

Health Care

European Financial

  • Also known as Know Your Customer, or KYC, the rules are established as Anti-Money Laundering (AML) regulations that are roughly analogous to the IAL levels.
  • [file:///C:/Users/Tom/Downloads/LoA-rated%20Attribute%20Framework%20Proposal%20-%2020181017.pdf eKYC FOR REMOTE ON-BOARDING - DATA & LoA eKYC FRAMEWORK - PRIORITY GROUP 2 PROPOSAL FOR DISCUSSION]

References

  1. Jack Nicas, Oprah, Is That You? Most Likely, It's Not. 2018-07-08 New York Times page BU1

External References

  1. Synonyms include: Validated which typically is used with Assurance of claims, or Attested which typically is used with Assurance of User Devices.