Identification and authentication 

Overview

This updated standard is to help align existing IT practices around access controls to the requirements in NIST 800-171 (ID | 3.5.x) as well as industry best practices.

What is in this document:

  • Identity types and authentication mechanisms
  • MFA requirements
  • Device identity management
  • Key management

What is NOT in this document:

Policy reference

Purpose
This Identification and Authentication standard supports APM 30.10 Identity and Access Management Policy, APM 30.11 University Data Classification and Standards, APM 30.15 Password and Authentication Policy and other relevant university policies.

Scope
These standards are the minimum baseline for all managed and unmanaged systems that access, store or process University of Idaho data (see APM 30.14 C-6) or using University of Idaho technology resources (see APM 30.12 C-1) at the Low, Moderate- or High risk levels (see APM 30.11) not otherwise covered by an approved systems security plan.

Standards

U of I Office of Information Technology (OIT) is responsible for the content and management of these standards.

To request an exception to this standard contact: oit-security@uidaho.edu 

1. Identity types

Identify information system users, processes acting on behalf of users or devices accessing the system. This includes both local and network access.

  1. System Users
    1. Users are identified by a username tied to a Vandal number within Banner.
    2. Various account types exist to aid in identification and classification within APM 30.10 Identity and Access Management Policy section A-2 “Account Types”.
    3. These must meet the requirements defined in IT Password Standards
  2. Processes acting on behalf of users
    1. Process identities must map to functional accounts, as defined in APM 30.10, “allow identification of processes not interactively controlled by end users.” Wherever possible.
      1. These must meet the requirements defined in IT Password Standards7
    2. Functional account owners, as defined within toolbox, assume responsibility for actions taken by the functional account.
    3. If a functional account is not used, users triggering the process must be identified either via session or prior log event.
  3. Devices
    1. Devices identified are one or more of:
      1. The IP address and MAC address tied to identities within our Network Management System (NMS) for devices on University of Idaho-managed networks.
      2. Unique device identifier within Duo Device Health for applications.
      3. Unique system certificates issued by University of Idaho or OIT-approved certificate services.
      4. IP addresses or DNS names are used to identify systems defined within firewall policy, or other relevant controls as defined by OIT Security.
    2. The contact defined within NMS assumes responsibility for actions taken by the device if a logged-on user cannot be sufficiently identified within the time frame of an investigation.
  4. Local accounts
    1. Accounts with identities managed directly on systems or applications.
    2. Managed local accounts:
      1. Must be centrally-managed via OIT credential access tool.
      2. May be used for support purposes when other methods are not feasible.
      3. Usage must be recorded either via ticket or within a credential access tool.
      4. The credential access tool will trigger change the password automatically.
    3. Unmanaged local accounts must not be used when OIT-managed accounts are available.
      Permanent usage of local accounts on moderate- or high-risk systems is only allowed when defined within a system security plan.
    4. These must meet the requirements defined in IT Password Standards7
  5. Temp or Emergency accounts
    1. Must not be used when named user accounts are available.
    2. Can only be used on a temporary basis.
    3. Must be created/authorized, used and removed/deauthorized per use case.
    4. Creation, usage and removal must be recorded via ticket.
    5. Responsible party for Temp or Emergency accounts must be recorded.
    6. These must meet the requirements for defined in IT Password Standards7
2. Standard authentication mechanisms for systems and applications

For systems and applications with access to University of Idaho data, University of Idaho requires the use of OIT-managed authentication systems. In order of preference (lower preference options can only be used when high preference options are verified to be non-viable):

  1. University of Idaho SSO using OIDC or SAML or other OAUTH supported mechanisms. 
    1. CAS may only be used if OIDC or SAML are unavailable. 
    2. MFA will be applied by default.
  2. University of Idaho active directory using encrypted channels such as LDAPS, Kerberos or MSCHAPv2 with EAP.
    1. User to application traffic must also be via an encrypted channel such as HTTPS.
    2. Remote access to applications/systems including but not limited to RDP/SSH/HTTPS/FTPS must employ the use of MFA.
      1. Moderate and High risk must use University Managed MFA.
      2. Publicly accessible systems are assumed to be moderate-risk unless otherwise explicitly categorized.
      3. Where not feasible, other controls must be implemented to reduce risk required by OIT Security.
    3. User passwords must be obfuscated while being entered. They may have a de-obfuscation button.
  3. Local accounts.
    1. User to application traffic must be via an encrypted channel such as HTTPS.
      Application must employ the use of MFA if possible.
    2. Where not feasible, other controls must be implemented to reduce risk as required by OIT Security.
    3. User passwords must be obfuscated while entering.
    4. Login failures must not leak information regarding the user or their credentials.
3. Standard authentication mechanisms for networks

For network access to University of Idaho data, University of Idaho requires the direct connection to OIT-managed Network:

  1. Wired networks
    1. MAC address must be registered within NMS as per APM 30.14.
    2. Authorization for specific networks defined within its NMS record.
  2. Employee wireless
    1. Users are authenticated via WPA2 Enterprise occurs via MSCHAPv2 authentication to Active Directory protected by EAP.
    2. Devices may be authenticated via OIT-managed device certificates.
    3. Authorization for specific networks from account type and status, or certificate used.
    4. Employee or department devices unable to support network requirements such as WPA2 Enterprise, may use long term guest access.
    5. Network examples include: AirVandalGold, and eduroam.
  3. Student wireless
    1. Users are authenticated via WPA2 Enterprise occurs via MSCHAPv2 authentication to Active Directory protected by EAP.
    2. Authorization for specific networks from account type and status.
    3. Student devices unable to support network requirements such as WPA2 Enterprise, may use long-term guest access.
    4. Network examples include: AirVandalGold, AirVandalHome, and eduroam.
  4. Remote access VPN
    1. User and/or device are authenticated and verified against OIT-managed identity source.
    2. Devices may be authenticated via OIT-managed device certificates.
    3. Authorization for specific networks from account type, affiliation and group membership and or certificate used.
  5. Event networks
    1. May be tailored to the event requirements.
    2. Must be granted the level of network access required only for the purpose of the event.
      1. Event networks with access to moderate or high-risk systems are subject to additional requirements defined by OIT Security.
    3. Must log device identities.
      Device MAC address is a sufficient identity.
    4. Must have the ability to block specific device identities.
    5. Network examples include: AirVandalConference
  6. Guest and public networks
    1. Must be logically separated for all other networks.
    2. Must identify device identities.
      1. Devices are registered with email and/or phone number
    3. Must have the ability to block specific device identities.
    4. Long-term guest access may be granted for affiliated individuals.
    5. Network examples include: AirVandalGuest, eduroam.
  7. External networks
    1. Must match firewall policy prior to access as per SC Section D-1.
4. Certificate and key management

To ensure secure keys and secrets are secured they must be issued or approved by OIT.

Other references

  1. NIST SP800-171r2 (February 2020)
  2. NIST SP800-53r5 (September 2020)
  3. NIST SP800-63-3 (June 2017)
  4. NIST SP800-51-1 (2020)
  5. NIST SP800-56Br2 (2019)
  6. NIST glossary
  7. CMMC glossary
  8. System and Communications Protection standard
  9. What are Azure AD "Named Locations"?
  10. WiFi and connectivity
  11. IT Password standards

Definitions

  1. Authorized user

    Any appropriately cleared individual with a requirement to access an information system.

  2. Single Sign On (SSO)

    An identification method that enables users to log in to multiple applications and websites with one set of credentials.

  3. Multi-Factor Authentication (MFA)

    Using two or more authentication factors: typically, passwords, biometrics or tokens, to achieve authentication.

  4. Credential

    "A credential binds an authenticator to the subscriber, via an identifier, as part of the issuance process." (NIST SP 800-63-3)

  5. Identity (also referred to as an account)

    “The set of attribute values (i.e., characteristics) by which an entity is recognizable and that, within the scope of an identity manager’s responsibility, is sufficient to distinguish that entity from any other entity.” (CMMC Glossary)

  6. University of Idaho Network Management System (NMS)

    University of Idaho proprietary tool for managing networks, devices on networks and connections between networks.

  7. Virtual Private Network (VPN)

    “Protected information system link utilizing tunneling, security controls and endpoint address translation giving the impression of a dedicated line.” (NIST SP 800-53)

  8. University of Idaho managed networks

    Networks that are owned and controlled by University of Idaho. (see: What are Azure AD "Named Locations"?)

  9. Certificate

    “A digital document issued and digitally signed by the private key of a certificate authority that binds an identifier to a subscriber to a public key. The certificate indicates that the subscriber identified in the certificate has sole control and access to the private key.” (NIST SP 800-63-3)

  10. Unique system certificates

    X.509-based certificates that are dedicated to one and only one specific system.

  11. OIT-managed authentication systems

    A source of Identities of any type that are owned and maintained by University of Idaho Office of Information Technology (OIT).

  12. Long term guest access

    Access to Campus Bypass wireless network which operates similar to AirVandalGuest.

    1. Long-term refers to longer than 5 business days.

  13. Privileged functions

    Functions that can impact the confidentiality, integrity or availability of data including but not limited to changes to access permissions, roles, security configuration, changes directly to high-risk or non-public data of other users or that impact the security of high-risk or non-public data of other users.

  14. Affiliated individuals

    Individuals assigned appropriate “eduPersonAffiliation” (see Internet2 eduPerson Object Class schema) according to their relationship(s) with the university required by APM 30.10 B-2 j.

  15. Key

    “A value used to control cryptographic operations, such as decryption, encryption, signature generation or signature verification.” (NIST SP 800-63-3)

  16. PKI

    “A set of policies, processes, server platforms, software and workstations used for the purpose of administering certificates and public-private key pairs, including the ability to issue, maintain and revoke public key certificates.” (NIST SP 800-63-3)

  17. Certificate Authority Authorization (CAA)

    A record associated with a Domain Name Server (DNS) entry that specifies the CAs that are authorized to issue certificates for that domain. (NIST Glossary)

  18. Certificate Authority (CA)

    “The entity in a Public Key Infrastructure (PKI) that is responsible for issuing public key certificates and exacting compliance to a PKI policy. Also known as a Certification Authority.” (NIST SP 800-56Br2)

  19. Remote access

    Access to a system or application through a network connection.

Revision history

3/1/2024 — Minor updates

  • Minor formatting/wording/reference changes.

6/23/2023 — Original standard

  • Full re-write to align with NIST 800-171r2