Difference between revisions of "Federation Assurance Level 3"

Latest revision as of 20:46, 19 March 2023

Full Title

These proposed requirements are created with the goal of establishing Specifications to achieve Federation Assurance Level 3.

Context

• NIST SP 800-63-3C is the current definition of FAL requirements listed below.
• NIST has requested comments as to the need for a revision 4 of 800-63 which is sure to make changes in the last parts of 2021 that need to be accommodated. These requirements look forward to those changes.

Terminology

• NIST 800-63-3 Definitions and Abbreviations

Assertion: A statement from a verifier to an RP that contains information about a subscriber. Assertions may also contain verified attributes.

Assertion Reference: A data object, created in conjunction with an assertion, that identifies the verifier and includes a pointer to the full assertion held by the verifier.

• 21 CFR 1300.03 subset of glossary US DoJ DEA Diversion Control Division

Authentication means verifying the identity of the user as a prerequisite to allowing access to the information application.

Authentication protocol means a well specified message exchange process that verifies possession of a token to remotely authenticate a person to an application.

Biometric authentication means authentication based on measurement of the individual's physical features or repeatable actions where those features or actions are both distinctive to the individual and measurable.

Biometric subsystem means the hardware and software used to capture, store, and compare biometric data. The biometric subsystem may be part of a larger application. The biometric subsystem is an automated system capable of:

(1) Capturing a biometric sample from an end user.
(2) Extracting and processing the biometric data from that sample.
(3) Storing the extracted information in a database.
(4) Comparing the biometric data with data contained in one or more reference databases.
(5) Determining how well the stored data matches the newly captured data and indicating whether an identification or verification of identity has been achieved.

Cache means to download and store information on a local server or hard drive.

Certificate policy means a named set of rules that sets forth the applicability of the specific digital certificate to a particular community or class of application with common security requirements.

Certificate revocation list (CRL) means a list of revoked, but unexpired certificates issued by a certification authority.

Certification authority (CA) means an organization that is responsible for verifying the identity of applicants, authorizing and issuing a digital certificate, maintaining a directory of public keys, and maintaining a Certificate Revocation List.

Certified information systems auditor (CISA) means an individual who has been certified by the Information Systems Audit and Control Association as qualified to audit information systems and who performs compliance audits as a regular ongoing business activity.

Credential means an object or data structure that authoritatively binds an identity (and optionally, additional attributes) to a token possessed and controlled by a person.

Credential service provider (CSP) means a trusted entity that issues or registers tokens and issues electronic credentials to individuals. The CSP may be an independent third party or may issue credentials for its own use.

CSOS means controlled substance ordering system.

Digital certificate means a data record that, at a minimum—
(1) Identifies the certification authority issuing it;
(2) Names or otherwise identifies the certificate holder;
(3) Contains a public key that corresponds to a private key under the sole control of the certificate holder;
(4) Identifies the operational period; and
(5) Contains a serial number and is digitally signed by the certification authority issuing it.

Digital signature means a record created when a file is algorithmically transformed into a fixed length digest that is then encrypted using an asymmetric cryptographic private key associated with a digital certificate. The combination of the encryption and algorithm transformation ensure that the signer's identity and the integrity of the file can be confirmed.

Digitally sign means to affix a digital signature to a data file.

Electronic prescription means a prescription that is generated on an electronic application and transmitted as an electronic data file.

Electronic prescription application provider means an entity that develops or markets electronic prescription software either as a stand- alone application or as a module in an electronic health record application.

Electronic signature means a method of signing an electronic message that identifies a particular person as the source of the message and indicates the person's approval of the information contained in the message.

False match rate means the rate at which an impostor's biometric is falsely accepted as being that of an authorized user. It is one of the statistics used to measure biometric performance when operating in the verification or authentication task. The false match rate is similar to the false accept (or acceptance) rate.

False non-match rate means the rate at which a genuine user's biometric is falsely rejected when the user's biometric data fail to match the enrolled data for the user. It is one of the statistics used to measure biometric performance when operating in the verification or authentication task. The false match rate is similar to the false reject (or rejection) rate, except that it does not include the rate at which a biometric system fails to acquire a biometric sample from a genuine user.

FIPS means Federal Information Processing Standards. These Federal standards, as incorporated by reference in § 1311.08 of this chapter, prescribe specific performance requirements, practices, formats, communications protocols, etc., for hardware, software, data, etc.

FIPS 140-2, as incorporated by reference in § 1311.08 of this chapter, means the National Institute of Standards and Technology publication entitled "Security Requirements for Cryptographic Modules," a Federal standard for security requirements for cryptographic modules.

FIPS 180-2, as incorporated by reference in § 1311.08 of this chapter, means the National Institute of Standards and Technology publication entitled "Secure Hash Standard," a Federal secure hash standard.

FIPS 180-3, as incorporated by reference in § 1311.08 of this chapter, means the National Institute of Standards and Technology publication entitled "Secure Hash Standard (SHS)," a Federal secure hash standard.

FIPS 186-2, as incorporated by reference in § 1311.08 of this chapter, means the National Institute of Standards and Technology publication entitled "Digital Signature Standard," a Federal standard for applications used to generate and rely upon digital signatures.

FIPS 186-3, as incorporated by reference in § 1311.08 of this chapter, means the National Institute of Standards and Technology publication entitled "Digital Signature Standard (DSS)," a Federal standard for applications used to generate and rely upon digital signatures.

Hard token means a cryptographic key stored on a special hardware device (e.g., a PDA, cell phone, smart card, USB drive, one-time password device) rather than on a general purpose computer.

Identity proofing means the process by which a credential service provider or certification authority validates sufficient information to uniquely identify a person.

Installed electronic prescription application means software that is used to create electronic prescriptions and that is installed on a practitioner's computers and servers, where access and records are controlled by the practitioner.

Installed pharmacy application means software that is used to process prescription information and that is installed on a pharmacy's computers or servers and is controlled by the pharmacy.

Intermediary means any technology system that receives and transmits an electronic prescription between the practitioner and pharmacy.

Key pair means two mathematically related keys having the properties that:

(1) One key can be used to encrypt a message that can only be decrypted using the other key; and

(2) Even knowing one key, it is computationally infeasible to discover the other key.

NIST means the National Institute of Standards and Technology.

NIST SP 800-63-1, as incorporated by reference in § 1311.08 of this chapter, means the National Institute of Standards and Technology publication entitled "Electronic Authentication Guideline," a Federal standard for electronic authentication.

NIST SP 800-76-1, as incorporated by reference in § 1311.08 of this chapter, means the National Institute of Standards and Technology publication entitled "Biometric Data Specification for Personal Identity Verification," a Federal standard for biometric data specifications for personal identity verification.

Operating point means a point chosen on a receiver operating characteristic (ROC) curve for a specific algorithm at which the biometric system is set to function. It is defined by its corresponding coordinates—a false match rate and a false non-match rate. An ROC curve shows graphically the trade-off between the principal two types of errors (false match rate and false non-match rate) of a biometric system by plotting the performance of a specific algorithm on a specific set of data.

Password means a secret, typically a character string (letters, numbers, and other symbols), that a person memorizes and uses to authenticate his identity.

PDA means a Personal Digital Assistant, a handheld computer used to manage contacts, appointments, and tasks.

Private key means the key of a key pair that is used to create a digital signature.

• Public key means the key of a key pair that is used to verify a digital signature. The public key is made available to anyone who will receive digitally signed messages from the holder of the key pair.
• Public Key Infrastructure (PKI) means a structure under which a certification authority verifies the identity of applicants; issues, renews, and revokes digital certificates; maintains a registry of public keys; and maintains an up-to-date certificate revocation list.
• Readily retrievable means that certain records are kept by automatic data processing applications or other electronic or mechanized recordkeeping systems in such a manner that they can be separated out from all other records in a reasonable time and/or records are kept on which certain items are asterisked, redlined, or in some other manner visually identifiable apart from other items appearing on the records.
• SAS 70 Audit means a third-party audit of a technology provider that meets the American Institute of Certified Public Accountants (AICPA) Statement of Auditing Standards (SAS) 70 criteria.
• Signing function means any keystroke or other action used to indicate that the practitioner has authorized for transmission and dispensing a controlled substance prescription. The signing function may occur simultaneously with or after the completion of the two-factor authentication protocol that meets the requirements of part 1311 of this chapter. The signing function may have different names (e.g., approve, sign, transmit), but it serves as the practitioner's final authorization that he intends to issue the prescription for a legitimate medical reason in the normal course of his professional practice.
• SysTrust means a professional service performed by a qualified certified public accountant to evaluate one or more aspects of electronic systems.
• Third-party audit means an independent review and examination of records and activities to assess the adequacy of system controls, to ensure compliance with established policies and operational procedures, and to recommend necessary changes in controls, policies, or procedures.
• Token means something a person possesses and controls (typically a key or password) used to authenticate the person's identity.
• Trusted agent means an entity authorized to act as a representative of a certification authority or credential service provider in confirming practitioner identification during the enrollment process.
• Valid prescription means a prescription that is issued for a legitimate medical purpose by an individual practitioner licensed by law to administer and prescribe the drugs concerned and acting in the usual course of the practitioner's professional practice.
• WebTrust means a professional service performed by a qualified certified public accountant to evaluate one or more aspects of Web sites.

Use Case

This use case is abstracted from 21 CFR PART 1311 —REQUIREMENTS FOR ELECTRONIC ORDERS AND PRESCRIPTIONS

• Federal Register Notices > Rules - 2020 > Electronic Prescriptions for Controlled Substances accepted change requests through 2020-06-22. No new rule is known at this time.
• 1311.05 Standards for technologies for electronic transmission of orders using digital signatures and PKI.

  A registrant or a person with power of attorney to sign orders for Schedule I and II controlled substances may use any technology to sign and electronically transmit orders if the technology provides all of the following:

1. Authentication: The system must enable a recipient to positively verify the signer without direct communication with the signer and subsequently demonstrate to a third party, if needed, that the sender's identity was properly verified.
2. Nonrepudiation: The system must ensure that strong and substantial evidence is available to the recipient of the sender's identity, sufficient to prevent the sender from successfully denying having sent the data. This criterion includes the ability of a third party to verify the origin of the document.
3. Message integrity: The system must ensure that the recipient, or a third party, can determine whether the contents of the document have been altered during transmission or after receipt.

• 1311.30 Requirements for storing and using a private key for digitally signing orders.

  (n.b. This appears to equate the public key with the holder's ID.)

1. Only the certificate holder may access or use his or her digital certificate and private key.
2. The certificate holder must provide FIPS-approved secure storage for the private key, as discussed by FIPS 140-2, 180-2, 186-2, and accompanying change notices and annexes, as incorporated by reference in Sec. 1311.08.
3. A certificate holder must ensure that no one else uses the private key. While the private key is activated, the certificate holder must prevent unauthorized use of that private key.
4. A certificate holder must not make back-up copies of the private key.
5. The certificate holder must report the loss, theft, or compromise of the private key or the password, via a revocation request, to the Certification Authority within 24 hours of substantiation of the loss, theft, or compromise. Upon receipt and verification of a signed revocation request, the Certification Authority will revoke the certificate. The certificate holder must apply for a new certificate under the requirements of Sec. 1311.25.
6. (.35) A purchaser of Schedule I and II controlled substances must obtain a separate CSOS certificate for each registered location for which the purchaser will order these controlled substances.

• 1311.50 Requirements for recipients of digitally signed orders.

  The recipient of a digitally signed order must do the following before filling the order:

1. Verify the integrity of the signature and the order by having the system validate the order.
2. Verify that the certificate holder's CSOS digital certificate has not expired by checking the expiration date against the date the order was signed.
3. Check the validity of the certificate holder's certificate by checking the Certificate Revocation List.
4. Check the certificate extension data to determine whether the sender has the authority to order the controlled substance.

• 1311.55 Requiremens for systems of both holder and RP = certified security module and crypto, protection for password and private key (hardware does not appear to be required for signing, but for storage.) Anti-hammering, secure clock, logs, check cert current.

Problems with 63-3C

1. The spec deliberately conflates CSP with IdP. That seems to disallow the user of Self-issued Identifier or Self-Sovereign Identity.
2. The spec treats the CSP/IdP as a single entity when distributed systems are now becoming common. Even the DEA implementation of a federation for prescribers and pharmacies is distributed with state control of some aspects.

Requirements for Today

General reqirments for all levels

1. The subscriber authenticates to the IdP and the result of that authentication event is asserted to the RP (verifies Credential and optionally provides attributes.)
2. Additional attributes MAY be made available through a secondary protocol protected by an authorized credential.
3. From an IdP’s perspective, the federation consists of the RPs that it serves and vice-versa.
4. IdPs and RPs may act as their own authorities or may use an external authority.
5. Key exchange SHALL be secure (public keys required except for pairwise interop.)
6. Federation SHALL establish parameters to exchange expected and acceptable levels.
7. Dynamic registration is optional but shall exchange parameters to minimize human intervention.
8. IdPs require consent of the subscriber to release user attributes. (It is not clear that this applies to notification call back addresses.)
9. IdPs MUST NOT make authentication dependent on user consent to release other attributes.
10. Software statements are required signed by appropriate authority.
11. Authorities, when used, vet the participants and their expected security, identity and privacy standards.
12. IdPs are trusted to see authentications among members and so must treat data as PII.
13. Cached Authentication is optional, but SHALL NOT assume that termination will propagate to RPs. (Whih is not to say it should not send a logout, only that is cannot assume it worked.)
14. Assertions (ie ID or similar tokens) SHALL include sub iss, aud, iat, exp, uniqueID, authN time, signature.
15. Assertions can be bearer, but may require binding to prevent assertion injection to prevent fraud. Reise protection is required.
16. Encyrpotion is required, but TLS sounds sufficient. Audience restriction is required, but necessary by the encryption.
17. If pairwise identifiers are used, there SHALL be no PII and the identifier must be unguessable.
18. If a common sub is used a privacy assessment is required.
19. Any tracking between RPs must only be permitted if all the RPs sharing the data are part of the Authority.
20. Complex rules are applied to assertion Presentation that can all be avoided if bound tokens are required.
21. Any solutiotion must allow for Self-issued Identifier or Self-Sovereign Identity.

FAL requirements

1. Bearer assertion, signed by IdP.
2. Bearer assertion, signed by IdP and encrypt to RP.
3. Holer of key assertion, signed by IdP and encrypt to RP.

FAL 2 requirements

Encryptions to RP.

FAL 3 requirements

Holder-of-key assertions MUST represent subscriber (sub) with references to the key and a signature directed to the RP. This must show poseesion or control of key.

A holder-of-key assertion contains a reference to a key possessed by and representing the subscriber. The key referenced in a holder-of-key represents the subscriber, not any other party in the system including the browser, IdP, or RP. Note that the reference to the key is asserted (and signed) by the issuer of the assertion.

When the RP receives the holder-of-key assertion, the subscriber proves possession of the key referenced in the assertion directly to the RP. While the subscriber could also have used a key-based means of authenticating to the IdP, the primary authentication at the IdP and the federated authentication at the RP are considered separately and are not assumed to use the same keys or related sessions.

In proving possession of the subscriber’s key to the RP, the claimant also proves with a certain degree of assurance that they are the rightful subject of the assertion. It is more difficult for an attacker to use a stolen holder-of-key assertion issued to a subscriber, since the attacker would need to steal the referenced key material as well.

The following requirements apply to all holder-of-key assertions:

1. The subscriber SHALL prove possession of that key to the RP, in addition to presentation of the assertion itself.
2. An assertion containing a reference to a key held by the subscriber for which key possession has not been proven SHALL be considered a bearer assertion by the RP.
3. Reference to a given key SHALL be trusted at the same level as all other information within the assertion.
4. The assertion SHALL NOT include an unencrypted private or symmetric key to be used with holder-of-key presentation.
5. The key MAY be distinct from any key used by the subscriber to authenticate to the IdP.
6. The key MAY be a symmetric key or a public key that corresponds to a private key.
7. The RP MAY verify the claimant’s possession of the key in conjunction with the IdP, for example, by requesting that the IdP verify a signature or MAC calculated by the claimant in response to a cryptographic challenge.

Four options are understood from this, plus a fifth that goes beyond 63-3C,

1. The federation has one sub per subscriber and any IdP can request of holder-of-key with a simple nonce to avoid replay. That hok response can be sent to any RP in the federation. The IdP confirms the nonce was matched.
2. The federation supports self-issued sub so that the user can be whomever they wish for each RP.
3. The federation requires pairwise unique subs for each RP-IdP pair and the Idp accepts the burnden of acquiring an FAL 3 holder of key assertion for any RP that requests it.
4. The federation allows each IdP to get a holder-of-key assertion from the sub and just inform the RP that the hok process was successful.
5. The federation allows the RP to complete the proof-of-key and proof-of-presence functions without input from the IdP by, for example, giving the user a separate authenticator in a hardware device which may be separate from the primary user access device.

Review of bearer assertion as holder-of-key assertions appears to be impractical in normal transactions. These are the conditions that must apply for a bearer token to be accepted.

1. The token must be signed by a key that is referenced in the token.
2. The token must be bound to a contemporaneous session between the sub and the IdP. This requires some sort of liveliness test of the sub by the IdP to prove no replay was attempted.
3. The token must be sent to the RP by the IdP on the back channel.
4. The IdP must assert to the RP that the bearer token has been created by the holder-of-key within the session time-out period.
5. The IdP must bind the token to the sub agreed to between the RP and the IdP.
6. All assertions generated by IdPs require the IdP to sign them. It seems that Holder-of-Key Assertions have their own definition of signer as the issuer of the assertion. And that the reference to a give key is only trusted to the extent that they holder is trust. But since the holder-of-hey is not yet trusted at level 3 until the holder-of-key is is trusted at level 3, there is an infinite loop of trust that is never resolved. The IdP is required to break this infinite loop in some unspecified way, but it is probably better to just insist on not trying to accept bearer holder-of-key assertions. Which means that first the IdP must assure that the key is under the control of the sub and then sent a nonce to the sub as ask it to be signed by the holder of key. It remains an open question if the above loop can be closed in any less intrusive manner.

The following path assumes that the holder-of-key is not a bearer token.

1. The sub, as understood by the IdP is authenticated at level 3 with the IdP. Since is a simple 2 party AAL3 process.
2. The RP asks the IdP for holder-of-key assertions.
3. The IdP sends a request to be defined to the sub with some unguessable value, or just with the pairwise sub that will be used with the RP.
4. The Holder creates a key to be used with the nonce or pairwise sub and signs a response to be created. (for self-issued IDs the Holder creates the pair-wise sub and a key to go with it.)
5. The response is sent to the RP by the IdP, with a binding to the pairwise sub if that is not implicit in the request.

Note that federations as know today generally use a common sub throughout the community which makes the extra step unnecessary if that is part of the federation's policy.

For the Future

Fix the spec to explicitly allow the following:

1. separable functions that make more use of cerdential providers that a a distinct from the IdP. These could be CSPs or Verifiable Credential providers, etc.
2. Self-issued Identifier or Self-Sovereign Identity.

References