Guías de Identidad Digital (Norma 800-63-3) - Consultoría en Ciberseguridad

Publicación especial NIST 800-63 revisión 3

NIST Publicación Especial 800-63, Revisión 3

1 Propósito

Esta sección es informativa.

Esta recomendación y sus volúmenes complementarios, Publicación Especial (SP) 800-63A, SP 800-63B y SP 800-63C, proporcionan directrices técnicas a las agencias para la implementación de la autenticación digital.

2 Introducción

Esta sección es informativa.

La identidad digital es la representación única de un sujeto involucrado en una transacción en línea. Una identidad digital siempre es única en el contexto de un servicio digital, pero no necesariamente tiene que identificar de manera única al sujeto en todos los contextos. En otras palabras, acceder a un servicio digital no implica que se conozca la identidad real del sujeto. La verificación de identidad establece que un sujeto es quien dice ser. La autenticación digital es el proceso de determinar la validez de uno o más autenticadores utilizados para reclamar una identidad digital. La autenticación establece que un sujeto que intenta acceder a un servicio digital tiene control sobre las tecnologías utilizadas para autenticar. La autenticación exitosa proporciona garantías razonables basadas en el riesgo de que el sujeto que accede al servicio hoy es el mismo que accedió al servicio anteriormente. La identidad digital presenta un desafío técnico porque este proceso a menudo implica verificar a individuos a través de una red abierta, y generalmente implica la autenticación de sujetos individuales a través de una red abierta para acceder a servicios gubernamentales digitales. Existen múltiples oportunidades para la suplantación y otros ataques que reclaman fraudulentamente la identidad digital de otro sujeto.

Esta recomendación proporciona a las agencias directrices técnicas para la autenticación digital de sujetos a sistemas federales a través de una red. También proporciona directrices para proveedores de servicios de credenciales (CSP), verificadores y partes que confían (RPs).

Estas directrices describen los procesos de gestión de riesgos para seleccionar servicios de identidad digital apropiados y los detalles para implementar niveles de aseguramiento de identidad, de autenticador y de federación basados en el riesgo. La orientación sobre evaluación de riesgos en estas directrices complementa el Marco de Gestión de Riesgos de NIST [NIST RMF] y sus publicaciones especiales componentes. Esta directriz no establece procesos adicionales de gestión de riesgos para las agencias. Más bien, los requisitos contenidos aquí proporcionan orientación específica relacionada con el riesgo de identidad digital mientras se ejecutan todas las fases relevantes del ciclo de vida del RMF.

La autenticación digital apoya la protección de la privacidad al mitigar los riesgos de acceso no autorizado a la información de las personas. Al mismo tiempo, debido a que la verificación de identidad, autenticación, autorización y federación implican el procesamiento de la información de las personas, estas funciones también pueden crear riesgos para la privacidad. Por lo tanto, estas directrices incluyen requisitos y consideraciones de privacidad para ayudar a mitigar los posibles riesgos de privacidad asociados.

Estas directrices apoyan la mitigación de los impactos negativos inducidos por un error de autenticación separando los elementos individuales de aseguramiento de identidad en partes discretas y componentes. Para los sistemas no federados, las agencias seleccionarán dos componentes, denominados Nivel de Aseguramiento de Identidad (IAL) y Nivel de Aseguramiento de Autenticador (AAL). Para los sistemas federados, se incluye un tercer componente, Nivel de Aseguramiento de Federación (FAL). La Sección 5, Gestión de Riesgos de Identidad Digital, proporciona detalles sobre el proceso de evaluación de riesgos. La Sección 6, Selección de Niveles de Aseguramiento, combina los resultados de la evaluación de riesgos con el contexto adicional para apoyar la selección por parte de las agencias de las combinaciones apropiadas de IAL, AAL y FAL basadas en el riesgo.

Estas directrices no consideran ni resultan en un nivel de aseguramiento compuesto (LOA) en el contexto de un único ordinal que impulse requisitos específicos de implementación. Más bien, al combinar la gestión de riesgos apropiada para los negocios, la seguridad y la privacidad junto con la necesidad de la misión, las agencias seleccionarán IAL, AAL y FAL como opciones distintas. Específicamente, este documento no reconoce el modelo de cuatro LOA utilizado anteriormente por las agencias federales y descrito en OMB M-04-04, en su lugar, requiere que las agencias seleccionen individualmente niveles correspondientes a cada función que se realice. Si bien muchos sistemas tendrán el mismo nivel numérico para cada IAL, AAL y FAL, esto no es un requisito, y las agencias no deben asumir que serán los mismos en cualquier sistema o aplicación dada.

Los componentes del aseguramiento de identidad detallados en estas directrices son los siguientes:

IAL (Identity Assurance Level) se refiere al proceso de verificación de identidad. Este proceso asegura que un sujeto es quien dice ser, estableciendo la autenticidad de la identidad en un contexto digital.
AAL (Authenticator Assurance Level) se refiere al proceso de autenticación. Este nivel mide la robustez del proceso de autenticación y asegura que el sujeto que está intentando acceder a un servicio digital tiene control sobre el autenticador utilizado.
FAL (Federation Assurance Level) se refiere al protocolo de aserción utilizado en un entorno federado para comunicar la información de autenticación y atributos (si corresponde) a una Parte Confiable (RP, por sus siglas en inglés). Este nivel es aplicable cuando se utiliza un entorno federado para compartir la identidad digital entre diferentes sistemas o servicios.

SP 800-63 Digital Identity Guidelines se organiza en una serie de volúmenes que cubren diferentes aspectos de la identidad digital y la autenticación. Aquí tienes un resumen de cada volumen:

SP 800-63 Digital Identity Guidelines: Proporciona la metodología de evaluación de riesgos y una visión general de los marcos de identidad digital, el uso de autenticadores, credenciales y aserciones en un sistema digital, y un proceso basado en el riesgo para seleccionar los niveles de garantía. Contenido: Contiene tanto material normativo como informativo.

SP 800-63A Enrollment and Identity Proofing: Aborda cómo los solicitantes pueden probar su identidad y ser inscritos como sujetos válidos dentro de un sistema de identidad. Proporciona requisitos para los procesos de prueba e inscripción en tres niveles diferentes de mitigación de riesgos, tanto en escenarios remotos como presenciales. Contenido: Contiene tanto material normativo como informativo.

SP 800-63B Authentication and Lifecycle Management: Aborda cómo un individuo puede autenticarse de manera segura ante un proveedor de servicios de credenciales (CSP) para acceder a un servicio digital o conjunto de servicios. Este volumen también describe el proceso de vinculación de un autenticador a una identidad. Contenido: Contiene tanto material normativo como informativo.

SP 800-63C Federation and Assertions: Proporciona requisitos sobre el uso de arquitecturas de identidad federada y aserciones para transmitir los resultados de los procesos de autenticación e información relevante de identidad a una aplicación de una agencia. También ofrece técnicas de mejora de la privacidad para compartir información sobre un sujeto válido y autenticado, y describe métodos que permiten la autenticación multifactor (MFA) fuerte mientras el sujeto sigue siendo seudónimo para el servicio digital. Contiene tanto material normativo como informativo.

NIST anticipa que los volúmenes individuales en estas directrices se revisarán de manera asincrónica. Siempre se debe usar la revisión más reciente de cada uno. Para minimizar el riesgo de errores de compatibilidad, una referencia al documento base (es decir, SP 800-63 en lugar de SP 800-63-3) siempre se refiere a la versión actual del documento.

Nombre de la Sección	Normativa/Informativa
1. Propósito	Informativa
2. Introducción	Informativa
3. Definiciones y Abreviaturas	Informativa
4. Modelo de Identidad Digital	Informativa
5. Gestión de Riesgos de Identidad Digital	Normativa
6. Selección de Niveles de Garantía	Normativa
7. Consideraciones sobre Federación	Informativa
8. Referencias	Informativa

2.1 Aplicabilidad

No todos los servicios digitales requieren autenticación o verificación de identidad; sin embargo, esta guía se aplica a todas aquellas transacciones para las cuales se requiere identidad digital o autenticación, independientemente del tipo de usuario (por ejemplo, ciudadanos, socios comerciales, entidades gubernamentales).

Las transacciones no cubiertas por esta guía incluyen aquellas asociadas con sistemas de seguridad nacional, según se define en 44 U.S.C. § 3542(b)(2). Las organizaciones del sector privado y los gobiernos estatales, locales y tribales cuyos procesos digitales requieren diferentes niveles de garantía pueden considerar el uso de estos estándares cuando sea apropiado.

Estas directrices se centran principalmente en los servicios de agencias que interactúan con la fuerza laboral no federal, como ciudadanos que acceden a beneficios o socios del sector privado que acceden a espacios de colaboración para compartir información. Sin embargo, también se aplican a los sistemas internos de las agencias a los que acceden empleados y contratistas. Se espera que estos usuarios posean una credencial válida emitida por el gobierno, principalmente la tarjeta de Verificación de Identidad Personal (PIV) o una PIV derivada. Por lo tanto, SP 800-63A y SP 800-63B son secundarias a los requisitos de FIPS 201 y su conjunto correspondiente de publicaciones especiales e instrucciones específicas de la agencia. Sin embargo, SP 800-63C y la selección basada en riesgos de un FAL apropiado se aplican, independientemente del tipo de credencial que posea el usuario interno. La selección de FAL proporciona orientación y flexibilidad a las agencias sobre cómo habilitar PIV en sus aplicaciones según el riesgo del sistema.

2.2 Consideraciones, Otros Requisitos y Flexibilidades

2.3 Algunas Limitaciones

Estas directrices técnicas no abordan la autenticación de sujetos para acceso físico (por ejemplo, a edificios), aunque algunos autenticadores utilizados para el acceso digital también pueden usarse para la autenticación de acceso físico. Además, esta revisión de estas directrices no aborda explícitamente la identidad de dispositivos, a menudo referida como autenticación máquina a máquina (como enrutador a enrutador) o dispositivos interconectados, comúnmente conocidos como el internet de las cosas (IoT). Dicho esto, estas directrices están escritas para referirse a sujetos genéricos siempre que sea posible, para dejar abierta la posibilidad de aplicabilidad a dispositivos. También se excluyen los requisitos específicos para la emisión de autenticadores a dispositivos cuando se utilizan en protocolos de autenticación con personas.

2.4 Cómo Usar esta Serie de SPs

El modelo de negocio, el mercado y la composición de cómo se entregan los servicios de identidad han cambiado drásticamente desde que se lanzó la primera versión del SP 800-63. En particular, los Proveedores de Servicios de Credenciales (CSPs) pueden estar compuestos por múltiples entidades comerciales que operan de manera independiente. Además, puede haber un beneficio significativo de seguridad al usar autenticadores fuertes, incluso si no se requiere la prueba de identidad. Por lo tanto, en esta revisión, se ha creado una serie de SPs bajo el nombre de 800-63 para facilitar estos nuevos modelos y hacer que sea fácil acceder a los requisitos específicos para la función que una entidad puede desempeñar bajo el modelo general de identidad digital.

2.5 Historial de cambios

2.5.1 SP 800-63-1

NIST SP 800-63-1 actualizó NIST SP 800-63 para reflejar las tecnologías actuales de autenticadores (entonces denominados “tokens”) y reestructuró el documento para proporcionar una mejor comprensión del modelo arquitectónico de identidad digital utilizado aquí. Se especificaron requisitos técnicos adicionales (mínimos) para el Proveedor de Servicios de Credenciales (CSP), los protocolos utilizados para transportar la información de autenticación y las aserciones si se implementan dentro del modelo de identidad digital.

2.5.2 SP 800-63-2

NIST SP 800-63-2 fue una actualización limitada de SP 800-63-1 y se realizaron cambios sustanciales únicamente en la Sección 5, Procesos de Registro y Emisión. Los cambios sustanciales en el borrador revisado estaban destinados a facilitar el uso de credenciales profesionales en el proceso de prueba de identidad y a reducir la necesidad de enviar correo postal a una dirección de registro para emitir credenciales para el registro remoto de nivel 3. Otros cambios en la Sección 5 fueron explicaciones y aclaraciones menores.

2.5.3 SP 800-63-3

NIST SP 800-63-3 es una actualización y reestructuración sustancial de SP 800-63-2. SP 800-63-3 introduce componentes individuales de garantía de autenticación — AAL, IAL y FAL — para apoyar la creciente necesidad de tratamiento independiente de la fuerza de autenticación y la confianza en la identidad reclamada de un individuo (por ejemplo, en la autenticación pseudónima fuerte). Se ha incluido una metodología de evaluación de riesgos y su aplicación a IAL, AAL y FAL en esta guía. También mueve toda la guía de identidad digital cubierta en SP 800-63 de un único documento que describe la autenticación a una serie de cuatro documentos (para abordar por separado los componentes individuales mencionados anteriormente) de los cuales SP 800-63-3 es el documento de nivel superior.

Otros aspectos actualizados en 800-63-3 incluyen:

Cambio de nombre a “Digital Identity Guidelines” para representar adecuadamente el alcance que incluye la prueba de identidad y la federación, y para apoyar la expansión del alcance para incluir la identidad de dispositivos o autenticación máquina a máquina en futuras revisiones.
Cambios en la terminología, incluyendo el uso de “authenticator” en lugar de “token” para evitar la confusión con el uso de la palabra token en tecnologías de aserción.
Actualizaciones en los requisitos de autenticación y aserción para reflejar avances en tecnología de seguridad y amenazas.
Requisitos sobre el almacenamiento de secretos a largo plazo por parte de los verificadores.
Modelo de prueba de identidad reestructurado.
Requisitos actualizados sobre la prueba de identidad remota.
Aclaración sobre el uso de canales y dispositivos independientes como “algo que tienes”.
Eliminación de los tokens de conocimiento pre-registrados (authenticators), reconociendo que son casos especiales de contraseñas (a menudo muy débiles).
Requisitos sobre la recuperación de cuentas en caso de pérdida o robo de un authenticator.
Eliminación del correo electrónico como canal válido para authenticators fuera de banda.
Discusión ampliada sobre la reautenticación y gestión de sesiones.
Discusión ampliada sobre la federación de identidad; reestructuración de las aserciones en el contexto de la federación.

3 Definiciones y abreviaturas

Consulta el Apéndice A para un conjunto completo de definiciones y abreviaturas.

4 Modelo de Identidad Digital

Esta sección es informativa.

4.1 Resumen

El modelo de identidad digital utilizado en estas directrices refleja las tecnologías y arquitecturas actualmente disponibles en el mercado. Existen modelos más complejos que separan funciones — como la emisión de credenciales y la provisión de atributos — entre un mayor número de partes, y que pueden tener ventajas en algunas clases de aplicaciones. Aunque se utiliza un modelo más sencillo en este documento, esto no impide que las agencias separen estas funciones. Además, ciertos procesos de inscripción, verificación de identidad y emisión realizados por el CSP a veces se delegan a una entidad conocida como autoridad de registro (RA) o gestor de identidad (IM). Una relación estrecha entre la RA y el CSP es típica, y la naturaleza de esta relación puede variar entre RAs, IMs y CSPs. El tipo de relación y sus requisitos están fuera del alcance de este documento. En consecuencia, el término CSP incluirá funciones de RA e IM. Finalmente, un CSP puede ofrecer otros servicios además de los servicios de identidad digital. En estas situaciones, los requisitos especificados en estas directrices solo se aplican a las funciones del CSP, no a los servicios adicionales.

La identidad digital es la representación única de un sujeto involucrado en una transacción en línea. El proceso utilizado para verificar la asociación de un sujeto con su identidad del mundo real se denomina verificación de identidad. En estas directrices, a la parte que se debe verificar se le llama solicitante. Cuando el solicitante completa exitosamente el proceso de verificación, se le conoce como suscriptor.

La fuerza de la verificación de identidad se describe mediante una medición ordinal llamada IAL. En IAL1, no se requiere verificación de identidad, por lo que cualquier información sobre atributos proporcionada por el solicitante se considera autoafirmada, o debe tratarse como autoafirmada y no verificada (incluso si es proporcionada por un CSP a un RP). IAL2 e IAL3 requieren verificación de identidad, y el RP puede solicitar al CSP que afirme información sobre el suscriptor, como valores de atributos verificados, referencias de atributos verificados o identificadores seudónimos. Esta información ayuda al RP a tomar decisiones de autorización. Un RP puede decidir que requiere IAL2 o IAL3, pero puede necesitar solo atributos específicos, lo que resulta en que el sujeto mantenga cierto grado de seudonimato. Este enfoque que mejora la privacidad es una ventaja de separar la fuerza del proceso de verificación de la del proceso de autenticación. Un RP también puede emplear un enfoque de identidad federada donde el RP subcontrata toda la verificación de identidad, recopilación de atributos y almacenamiento de atributos a un CSP.

En estas directrices, a la parte que se autentica se le llama reclamante y a la parte que verifica esa identidad se le llama verificador. Cuando un reclamante demuestra exitosamente la posesión y control de uno o más autenticadores a un verificador a través de un protocolo de autenticación, el verificador puede verificar que el reclamante es un suscriptor válido. El verificador transmite una afirmación sobre el suscriptor, que puede ser seudónimo o no seudónimo, al RP. Esa afirmación incluye un identificador y puede incluir información de identidad sobre el suscriptor, como el nombre, u otros atributos que fueron recopilados en el proceso de inscripción (sujeto a las políticas del CSP, las necesidades del RP y el consentimiento para la divulgación de atributos dado por el sujeto). Cuando el verificador también es el RP, la afirmación puede ser implícita. El RP puede usar la información autenticada proporcionada por el verificador para tomar decisiones de autorización.

La autenticación establece la confianza en que el reclamante posee un (o varios) autenticador(es) asociado(s) a la credencial, y en algunos casos en los valores de atributos del suscriptor (por ejemplo, si el suscriptor es ciudadano de EE.UU., es estudiante en una universidad en particular, o se le asigna un número o código particular por una agencia u organización). La autenticación no determina las autorizaciones o privilegios de acceso del reclamante; esta es una decisión separada y está fuera del alcance de estas directrices. Los RPs pueden usar la identidad autenticada y los atributos de un suscriptor junto con otros factores para tomar decisiones de autorización. Nada en este conjunto de documentos impide que los RPs soliciten información adicional a un suscriptor que se ha autenticado exitosamente.

La fuerza del proceso de autenticación se describe mediante una medición ordinal llamada AAL. AAL1 requiere autenticación de un solo factor y se permite con una variedad de tipos de autenticadores. En AAL2, la autenticación requiere dos factores de autenticación para mayor seguridad. La autenticación en el nivel más alto, AAL3, requiere además el uso de un autenticador basado en hardware y resistencia a la suplantación de verificador.

Las diversas entidades e interacciones que comprenden el modelo de identidad digital utilizado aquí se ilustran en la Figura 4-1.

Figura 4-1 Modelo de Identidad Digital

El lado izquierdo del diagrama muestra las actividades de inscripción, emisión de credenciales, gestión del ciclo de vida y diversos estados de un proceso de verificación de identidad y autenticación. La secuencia habitual de interacciones es la siguiente:

Un solicitante solicita a un CSP a través de un proceso de inscripción.
El CSP verifica la identidad de ese solicitante. Tras una verificación exitosa, el solicitante se convierte en suscriptor.
Se establecen autenticador(es) y una credencial correspondiente entre el CSP y el suscriptor.
El CSP mantiene la credencial, su estado y los datos de inscripción recopilados durante la vida útil de la credencial (como mínimo). El suscriptor mantiene su(s) autenticador(es).

Otras secuencias son menos comunes, pero también podrían lograr los mismos requisitos funcionales.

El lado derecho de la Figura 4-1 muestra las entidades y las interacciones involucradas en el uso de un autenticador para realizar una autenticación digital. Un suscriptor se denomina reclamante cuando necesita autenticarse ante un verificador. Las interacciones son las siguientes:

El reclamante demuestra la posesión y el control del o los autenticadores al verificador a través de un protocolo de autenticación.
El verificador interactúa con el CSP para validar la credencial que vincula la identidad del suscriptor con su autenticador y, opcionalmente, obtener atributos del reclamante.
El CSP o el verificador proporcionan una afirmación sobre el suscriptor al RP, que puede usar la información en la afirmación para tomar una decisión de autorización.
Se establece una sesión autenticada entre el suscriptor y el RP.

En todos los casos, el RP debe solicitar los atributos que necesita al CSP antes de autenticar al reclamante. Además, se debe solicitar al reclamante su consentimiento para la liberación de esos atributos antes de la generación y liberación de una afirmación.

En algunos casos, el verificador no necesita comunicarse en tiempo real con el CSP para completar la actividad de autenticación (por ejemplo, algunos usos de certificados digitales). Por lo tanto, la línea discontinua entre el verificador y el CSP representa un enlace lógico entre las dos entidades. En algunas implementaciones, las funciones de verificador, RP y CSP pueden estar distribuidas y separadas como se muestra en la Figura 4-1. Sin embargo, si estas funciones residen en la misma plataforma, las interacciones entre los componentes son mensajes locales entre aplicaciones que se ejecutan en el mismo sistema en lugar de protocolos sobre redes compartidas y no confiables.

Como se mencionó anteriormente, un CSP mantiene información sobre el estado de las credenciales que emite. Los CSP generalmente asignarán una duración finita al emitir credenciales para limitar el período de mantenimiento. Cuando el estado cambia o cuando las credenciales están cerca de su vencimiento, las credenciales pueden renovarse o reemitirse; o bien, la credencial puede ser revocada y destruida. Normalmente, el suscriptor se autentica ante el CSP utilizando su autenticador y credencial existentes y no expirados para solicitar la emisión de un nuevo autenticador y credencial. Si el suscriptor no solicita la reemisión del autenticador y la credencial antes de su expiración o revocación, puede ser necesario repetir el proceso de inscripción para obtener un nuevo autenticador y credencial. Alternativamente, el CSP puede optar por aceptar una solicitud durante un período de gracia después de la expiración.

4.2 Inscripción y Verificación de Identidad

Los requisitos normativos se encuentran en SP 800-63A, Inscripción y Verificación de Identidad.

La sección anterior presentó a los participantes en el modelo conceptual de identidad digital. Esta sección proporciona detalles adicionales sobre las relaciones y responsabilidades de los participantes en la inscripción y verificación de identidad.

Un individuo, denominado solicitante en esta etapa, opta por ser verificado por un CSP. Si el solicitante es verificado exitosamente, el individuo se denomina suscriptor de ese CSP.

El CSP establece un mecanismo para identificar de manera única a cada suscriptor, registrar las credenciales del suscriptor y rastrear los autenticadores emitidos a ese suscriptor. El suscriptor puede recibir autenticadores en el momento de la inscripción, el CSP puede asociar autenticadores que el suscriptor ya posee, o estos pueden generarse más tarde según sea necesario. Los suscriptores tienen el deber de mantener el control de sus autenticadores y cumplir con las políticas del CSP para mantener activos los autenticadores. El CSP mantiene registros de inscripción para cada suscriptor para permitir la recuperación de autenticadores, por ejemplo, cuando se pierden o son robados.

4.3 Autenticación y Gestión del Ciclo de Vida

Los requisitos normativos se encuentran en SP 800-63B, Autenticación y Gestión del Ciclo de Vida.

4.3.1 Autenticadores

El paradigma clásico para los sistemas de autenticación identifica tres factores como los pilares de la autenticación:

Algo que sabes (por ejemplo, una contraseña).
Algo que tienes (por ejemplo, una credencial de identificación o una clave criptográfica).
Algo que eres (por ejemplo, una huella dactilar u otros datos biométricos).

La MFA (autenticación multifactor) se refiere al uso de más de uno de los factores anteriores. La fortaleza de los sistemas de autenticación se determina en gran medida por el número de factores incorporados en el sistema: cuanto más factores se empleen, más robusto será el sistema de autenticación. Para los fines de estas directrices, el uso de dos factores es adecuado para cumplir con los requisitos de seguridad más altos. Como se discute en la Sección 5.1, otros tipos de información, como los datos de ubicación o la identidad del dispositivo, pueden ser utilizados por un RP o verificador para evaluar el riesgo en una identidad reclamada, pero no se consideran factores de autenticación.

En la autenticación digital, el reclamante posee y controla uno o más autenticadores que han sido registrados con el CSP y se utilizan para probar la identidad del reclamante. El o los autenticadores contienen secretos que el reclamante puede usar para demostrar que es un suscriptor válido. El reclamante se autentica en un sistema o aplicación a través de una red demostrando que posee y controla uno o más autenticadores.

Los secretos contenidos en los autenticadores se basan en pares de claves públicas (claves asimétricas) o secretos compartidos (claves simétricas). Una clave pública y una clave privada relacionada forman un par de claves públicas. La clave privada se almacena en el autenticador y es utilizada por el reclamante para demostrar la posesión y control del autenticador. Un verificador, conociendo la clave pública del reclamante a través de algún tipo de credencial (típicamente un certificado de clave pública), puede usar un protocolo de autenticación para verificar la identidad del reclamante demostrando que el reclamante posee y controla el autenticador de clave privada asociado.

Los secretos compartidos almacenados en los autenticadores pueden ser claves simétricas o secretos memorizados (por ejemplo, contraseñas y PINs), en contraste con las claves asimétricas descritas anteriormente, que los suscriptores no necesitan compartir con el verificador. Aunque tanto las claves como las contraseñas pueden ser utilizadas en protocolos similares, una diferencia importante entre ambas es cómo se relacionan con el suscriptor. Mientras que las claves simétricas generalmente se almacenan en hardware o software que controla el suscriptor, las contraseñas están destinadas a ser memorizadas por el suscriptor. Dado que la mayoría de los usuarios eligen contraseñas cortas para facilitar la memorización y la entrada, las contraseñas suelen tener menos caracteres que las claves criptográficas. Además, mientras que los sistemas eligen claves al azar, los usuarios que intentan elegir contraseñas memorables a menudo seleccionan de un subconjunto muy pequeño de posibles contraseñas de una longitud dada, y muchas elegirán valores muy similares. Como tal, mientras que las claves criptográficas suelen ser lo suficientemente largas como para que los ataques de adivinanza basados en redes sean inviables, las contraseñas elegidas por el usuario pueden ser vulnerables, especialmente si no se han implementado defensas.

En este volumen, los autenticadores siempre contienen un secreto. Algunos de los factores de autenticación clásicos no se aplican directamente a la autenticación digital. Por ejemplo, una licencia de conducir física es algo que tienes y puede ser útil al autenticarte ante una persona (por ejemplo, un guardia de seguridad), pero no es en sí misma un autenticador para la autenticación digital. Los factores de autenticación clasificados como algo que sabes tampoco son necesariamente secretos. La autenticación basada en conocimiento, en la que se solicita al reclamante responder preguntas que se supone que solo conoce él, tampoco constituye un secreto aceptable para la autenticación digital. Un biométrico tampoco constituye un secreto. En consecuencia, estas directrices solo permiten el uso de biométricos para la autenticación cuando están firmemente vinculados a un autenticador físico.

Un sistema de autenticación digital puede incorporar múltiples factores de dos maneras:

El sistema puede implementarse de modo que se presenten múltiples factores al verificador; o
Algunos factores pueden usarse para proteger un secreto que se presentará al verificador.

Por ejemplo, el ítem 1 puede ser satisfecho emparejando un secreto memorizado (lo que sabes) con un dispositivo fuera de banda (lo que tienes). Ambos resultados del autenticador se presentan al verificador para autenticar al reclamante. Para el ítem 2, considere un dispositivo de hardware (el autenticador) que contiene una clave criptográfica (el secreto del autenticador) donde el acceso está protegido con una huella digital. Cuando se usa con el biométrico, la clave criptográfica produce una salida que se usa para autenticar al reclamante.

Como se mencionó anteriormente, los biométricos, cuando se emplean como un solo factor de autenticación, no constituyen secretos aceptables para la autenticación digital, pero tienen su lugar en la autenticación de identidades digitales. Las características biométricas son atributos personales únicos que se pueden usar para verificar la identidad de una persona que está físicamente presente en el punto de verificación. Incluyen características faciales, huellas dactilares, patrones de iris, impresiones de voz y muchas otras características. SP 800-63A, Inscripción y Verificación de Identidad recomienda que se recojan biométricos en el proceso de inscripción para ayudar a prevenir que un suscriptor registrado rechace la inscripción y para ayudar a identificar a quienes cometen fraude en la inscripción.

4.3.2 Credenciales

Como se describe en las secciones anteriores, una credencial vincula un autenticador al suscriptor, a través de un identificador, como parte del proceso de emisión. Una credencial es almacenada y mantenida por el CSP, aunque el reclamante puede poseerla. El reclamante posee un autenticador, pero no necesariamente está en posesión de la credencial. Por ejemplo, las entradas en la base de datos que contienen los atributos del usuario se consideran credenciales para los fines de este documento pero son poseídas por el verificador. Los certificados de clave pública X.509 son un ejemplo clásico de credenciales que el reclamante puede, y a menudo posee.

4.3.3 Proceso de Autenticación

El proceso de autenticación comienza con el reclamante demostrando al verificador la posesión y el control de un autenticador que está vinculado a la identidad afirmada a través de un protocolo de autenticación. Una vez que se ha demostrado la posesión y el control, el verificador verifica que la credencial siga siendo válida, generalmente interactuando con el CSP.

La naturaleza exacta de la interacción entre el verificador y el reclamante durante el protocolo de autenticación es extremadamente importante para determinar la seguridad general del sistema. Los protocolos bien diseñados pueden proteger la integridad y confidencialidad de la comunicación entre el reclamante y el verificador tanto durante como después de la autenticación, y pueden ayudar a limitar el daño que puede causar un atacante que se haga pasar por un verificador legítimo.

Además, los mecanismos ubicados en el verificador pueden mitigar los ataques de adivinanza en línea contra secretos de baja entropía — como contraseñas y PINs — limitando la tasa a la que un atacante puede hacer intentos de autenticación, o retrasando de otro modo los intentos incorrectos. Generalmente, esto se hace realizando un seguimiento y limitando el número de intentos fallidos, ya que la premisa de un ataque de adivinanza en línea es que la mayoría de los intentos fallarán.

El verificador es un rol funcional, pero a menudo se implementa en combinación con el CSP, el RP, o ambos. Si el verificador es una entidad separada del CSP, a menudo es deseable asegurarse de que el verificador no aprenda el secreto del autenticador del suscriptor en el proceso de autenticación, o al menos asegurarse de que el verificador no tenga acceso irrestricto a los secretos almacenados por el CSP.

4.4 Federación y Aserciones

Los requisitos normativos se pueden encontrar en SP 800-63C, Federación y Aserciones.

En general, SP 800-63 no presupone una arquitectura de identidad federada; más bien, estas directrices son neutrales con respecto a los tipos de modelos que existen en el mercado, permitiendo a las agencias implementar un esquema de autenticación digital según sus propios requisitos. Sin embargo, la federación de identidades se prefiere sobre una serie de sistemas de identidad aislados que cada uno sirve a una sola agencia o RP.

Las arquitecturas federadas tienen muchos beneficios significativos, incluyendo, pero no limitados a:

Mejora de la experiencia del usuario. Por ejemplo, un individuo puede ser probado una vez y reutilizar la credencial emitida en múltiples RPs.
Reducción de costos tanto para el usuario (reducción de autenticadores) como para la agencia (reducción en infraestructura de tecnología de la información).
Minimización de datos, ya que las agencias no necesitan pagar por la recolección, almacenamiento, eliminación y actividades de cumplimiento relacionadas con el almacenamiento de información personal.
Aserciones de atributos seudónimos, ya que las agencias pueden solicitar un conjunto minimizado de atributos, incluidos reclamos, para cumplir con la entrega de servicios.
Facilitación de la misión, ya que las agencias pueden enfocarse en la misión en lugar de en la gestión de identidades.

Las siguientes secciones discuten los componentes de una arquitectura de identidad federada en caso de que una agencia elija este tipo de modelo.

4.4.1 Aserciones

Al finalizar el proceso de autenticación, el verificador genera una aserción que contiene el resultado de la autenticación y la proporciona al RP. La aserción se utiliza para comunicar el resultado del proceso de autenticación, y opcionalmente, información sobre el suscriptor, del verificador al RP. Las aserciones pueden comunicarse directamente al RP o pueden ser enviadas a través del suscriptor, lo que tiene implicaciones adicionales para el diseño del sistema.

Un RP confía en una aserción en función de la fuente, el momento de creación, cuánto tiempo es válida la aserción desde el momento de creación y el marco de confianza correspondiente que gobierna las políticas y procesos de los CSP y RPs. El verificador es responsable de proporcionar un mecanismo mediante el cual se pueda confirmar la integridad de la aserción.

El RP es responsable de autenticar la fuente (el verificador) y de confirmar la integridad de la aserción. Cuando el verificador pasa la aserción a través del suscriptor, el verificador debe proteger la integridad de la aserción de manera que no pueda ser modificada. Sin embargo, si el verificador y el RP se comunican directamente, se puede usar una sesión protegida para preservar la integridad de la aserción. Al enviar aserciones a través de una red abierta, el verificador es responsable de garantizar que cualquier información sensible del suscriptor contenida en la aserción solo pueda ser extraída por un RP que confíe en mantener la confidencialidad de la información.

Ejemplos de aserciones incluyen:

Las aserciones del Lenguaje de Marcado de Aserciones de Seguridad (SAML) están especificadas utilizando un lenguaje de marcado destinado a describir aserciones de seguridad. Pueden ser utilizadas por un verificador para hacer una declaración a un RP sobre la identidad de un reclamante. Las aserciones SAML pueden ser opcionalmente firmadas digitalmente.
Las afirmaciones de OpenID Connect están especificadas utilizando JavaScript Object Notation (JSON) para describir seguridad y, opcionalmente, afirmaciones de usuario. Las afirmaciones de información de usuario en JSON pueden ser opcionalmente firmadas digitalmente.
Los tickets de Kerberos permiten a una autoridad emisora de tickets otorgar claves de sesión a dos partes autenticadas utilizando esquemas de encapsulación basados en clave simétrica.

4.4.2 Partes Confiables

Un RP confía en los resultados de un protocolo de autenticación para establecer confianza en la identidad o los atributos de un suscriptor con el propósito de realizar una transacción en línea. Los RPs pueden usar la identidad autenticada del suscriptor (seudónima o no seudónima), el IAL, AAL, y FAL (FAL indicando la fuerza del protocolo de aserción), y otros factores para tomar decisiones de autorización. El verificador y el RP pueden ser la misma entidad, o pueden ser entidades separadas. Si son entidades separadas, el RP normalmente recibe una aserción del verificador. El RP asegura que la aserción provino de un verificador en el que confía. El RP también procesa cualquier información adicional en la aserción, como atributos personales o tiempos de expiración. El RP es el árbitro final sobre si una aserción específica presentada por un verificador cumple con los criterios establecidos por el RP para el acceso al sistema, independientemente del IAL, AAL o FAL.

5 Gestión de Riesgos de Identidad Digital

Esta sección es normativa.

Esta sección y la guía correspondiente para la evaluación de riesgos complementan el Marco de Gestión de Riesgos (RMF) del NIST y sus publicaciones especiales componentes. Esto no establece procesos adicionales de gestión de riesgos para las agencias. En su lugar, los requisitos aquí contenidos proporcionan una guía específica relacionada con los riesgos de identidad digital que las agencias DEBEN aplicar mientras ejecutan todas las fases relevantes del ciclo de vida del RMF.

5.1 Visión General

En los servicios digitales de hoy en día, combinar los requisitos de verificación, autenticación y federación en un solo paquete a veces tiene consecuencias no deseadas y puede imponer una carga de implementación innecesaria en la organización que lo implementa. Es muy posible que una agencia pueda ofrecer el conjunto más efectivo de servicios de identidad evaluando el riesgo y los impactos de los fallos en cada componente individual de la autenticación digital, en lugar de como un solo nivel de aseguramiento global (LOA). Con este fin, estas directrices reconocen que un error de autenticación no es un elemento único que impulsa todos los requisitos.

Este volumen detalla los requisitos para ayudar a las agencias a evitar:

Errores en la verificación de identidad (es decir, un solicitante falso que reclama una identidad que no le pertenece);
Errores de autenticación (es decir, un reclamante falso que usa un credencial que no le pertenece); y
Errores de federación (es decir, una aserción de identidad comprometida).

Desde la perspectiva de una falla en la verificación de identidad, hay dos dimensiones de posible falla:

El impacto de proporcionar un servicio al sujeto equivocado (por ejemplo, un atacante que verifica con éxito como otra persona).
El impacto de una verificación de identidad excesiva (es decir, recopilar y almacenar de forma segura más información sobre una persona de la necesaria para proporcionar con éxito el servicio digital).

Por lo tanto, las agencias DEBEN evaluar el riesgo de errores de verificación, autenticación y federación por separado para determinar el nivel de aseguramiento requerido para cada transacción.

La Sección 5.3 proporciona categorías de impacto específicas para la identidad digital para ayudar en la aplicación general del RMF.

Las evaluaciones de riesgo determinan la medida en la que el riesgo debe ser mitigado por los procesos de verificación de identidad, autenticación y federación. Estas determinaciones impulsan las elecciones relevantes de tecnologías aplicables y estrategias de mitigación, en lugar de que el deseo de una tecnología específica impulse las determinaciones de riesgo. Una vez que una agencia haya completado la evaluación general de riesgos, seleccionado los niveles de aseguramiento individuales para la verificación de identidad, autenticación y federación (si corresponde), y determinado los procesos y tecnologías que emplearán para cumplir con cada nivel de aseguramiento, las agencias DEBEN desarrollar una "Declaración de Aceptación de Identidad Digital", de acuerdo con SP 800-53A IA-1 a.1. Consulte la Sección 5.5 para más detalles sobre el contenido necesario de la Declaración de Aceptación de Identidad Digital.

5.2 Niveles de Aseguramiento

Una agencia DEBE seleccionar, basándose en el riesgo, los siguientes niveles de aseguramiento individuales:

IAL (Identity Assurance Level): La solidez del proceso de verificación de identidad para determinar con confianza la identidad de una persona. El IAL se selecciona para mitigar posibles errores en la verificación de identidad.

AAL (Authentication Assurance Level): La solidez del proceso de autenticación en sí, y la vinculación entre un autenticador y el identificador específico de una persona. El AAL se selecciona para mitigar posibles errores de autenticación (es decir, un reclamante falso utilizando un credencial que no le pertenece).

FAL (Federation Assurance Level): La solidez del protocolo de aserción que la federación utiliza para comunicar la autenticación y la información de atributos (si corresponde) a un RP (Proveedor de Servicios). El FAL es opcional, ya que no todos los sistemas digitales aprovecharán las arquitecturas de identidad federada. El FAL se selecciona para mitigar posibles errores de federación (es decir, una aserción de identidad comprometida).

A continuación, se proporciona un resumen de cada uno de los niveles de aseguramiento de identidad, autenticación y federación.

Tabla 5-1 Niveles de Aseguramiento de Identidad

Nivel de Aseguramiento de Identidad

IAL1: En el nivel IAL1, los atributos, si los hay, son autodeclarados o deben tratarse como autodeclarados.

IAL2: En el nivel IAL2, se requiere la verificación de identidad, ya sea de forma remota o en persona. El IAL2 exige que los atributos de identificación hayan sido verificados en persona o de manera remota utilizando, como mínimo, los procedimientos indicados en SP 800-63A.

IAL3: En el nivel IAL3, se requiere la verificación de identidad en persona. Los atributos de identificación deben ser verificados por un representante autorizado del Proveedor de Servicios de Confianza (CSP) mediante el examen de documentación física, como se describe en SP 800-63A.

Tabla 5-2 Niveles de Aseguramiento de Autenticadores

Nivel de Aseguramiento de Autenticadores

AAL1: El AAL1 proporciona cierta garantía de que el reclamante controla un autenticador registrado al suscriptor. AAL1 requiere autenticación de un solo factor utilizando una amplia gama de tecnologías de autenticación disponibles. La autenticación exitosa requiere que el reclamante demuestre la posesión y control del(los) autenticador(es) a través de un protocolo de autenticación seguro.

AAL2: El AAL2 proporciona alta confianza de que el reclamante controla el(los) autenticador(es) registrado(s) al suscriptor. Se requiere prueba de posesión y control de dos factores de autenticación diferentes a través de un protocolo de autenticación seguro. Se requieren técnicas criptográficas aprobadas en AAL2 y niveles superiores.

AAL3: El AAL3 proporciona una confianza muy alta de que el reclamante controla el(los) autenticador(es) registrado(s) al suscriptor. La autenticación en AAL3 se basa en la prueba de posesión de una clave a través de un protocolo criptográfico. AAL3 es similar a AAL2, pero también requiere un autenticador criptográfico "físico" que ofrezca resistencia a la suplantación del verificador.

Tabla 5-3 Niveles de Aseguramiento de la Federación

Nivel de Aseguramiento de la Federación

FAL1: El FAL1 permite que el Proveedor de Servicios (RP) reciba una aserción de tipo "portador" de un proveedor de identidad (IdP). El IdP debe firmar la aserción utilizando criptografía aprobada.

FAL2: El FAL2 añade el requisito de que la aserción sea cifrada utilizando criptografía aprobada, de manera que el RP sea la única parte que pueda descifrarla.

FAL3: El FAL3 requiere que el suscriptor presente una prueba de posesión de una clave criptográfica referenciada en la aserción, junto con la propia aserción. La aserción debe ser firmada utilizando criptografía aprobada y cifrada para el RP utilizando criptografía aprobada.

Cuando se describen de manera genérica o combinada, estas directrices se referirán a IAL, AAL y FAL como xAL.

5.3 Riesgos e Impactos

Esta sección proporciona detalles sobre las categorías de impacto utilizadas para determinar los niveles IAL, AAL, y FAL.

Categorías de Impacto Potencial: Para determinar el nivel de aseguramiento apropiado de la identidad declarada del usuario, las agencias DEBEN evaluar los riesgos potenciales e identificar medidas para minimizar su impacto.

Los errores de autenticación, verificación y federación con consecuencias potencialmente más graves requieren niveles más altos de aseguramiento. Los procesos de negocio, políticas y tecnologías pueden ayudar a reducir el riesgo.

Las categorías de daño e impacto incluyen:

Inconveniencia, angustia o daño a la reputación o estatus;
Pérdida financiera o responsabilidad de la agencia;
Daño a los programas de la agencia o a los intereses públicos;
Divulgación no autorizada de información sensible;
Seguridad personal; y
Violaciones civiles o penales.

Los niveles de aseguramiento requeridos para transacciones digitales se determinan evaluando el impacto potencial de cada una de las categorías anteriores utilizando los valores de impacto potencial descritos en el Estándar Federal de Procesamiento de Información (FIPS) 199 [FIPS 199].

Los tres valores de impacto potencial son:

Impacto bajo,
Impacto moderado, y
Impacto alto.

5.3.1 Proceso de Negocio vs. Transacción en Línea

La determinación del nivel de aseguramiento se basa únicamente en transacciones que forman parte de un sistema digital. Una transacción en línea puede no ser equivalente a un proceso de negocio completo que requiera procesamiento fuera de línea, o procesamiento en línea en un sistema completamente segmentado. Al seleccionar los niveles de aseguramiento apropiados, la agencia debe evaluar el riesgo asociado con las transacciones en línea que ofrecen a través del servicio digital, no el proceso de negocio completo asociado con el beneficio o servicio proporcionado.

Por ejemplo, en una encuesta en línea, se puede recopilar información personal, pero esta nunca se pone a disposición en línea del remitente después de que la información se guarda. En este caso, es importante proteger cuidadosamente la información en los sistemas de backend, pero no hay razón para verificar la identidad o incluso autenticar al usuario que proporciona la información para acceder al sistema o a sus beneficios asociados. La transacción en línea es únicamente una entrega de datos. El proceso de negocio completo puede requerir una cantidad significativa de validación de datos, sin necesidad de saber si la persona correcta envió la información. En este escenario, no hay necesidad de verificación de identidad ni de autenticación.

Otro ejemplo donde el riesgo evaluado podría diferir si la agencia evaluara el proceso de negocio completo en lugar de los requisitos de la transacción en línea es un servicio digital que acepta currículums para postularse a vacantes de empleo. En este caso, el servicio digital permite que una persona envíe – o al menos no restringe a una persona de enviar – un currículum en nombre de otra persona, y en visitas posteriores al sitio, acceda al currículum para varios propósitos. Dado que la información del currículum está disponible para el usuario en sesiones posteriores, y es probable que contenga información personal, la agencia debe seleccionar un AAL que requiera autenticación multifactor (MFA), incluso si el usuario autodeclara la información personal. En este caso, se aplican los requisitos de la [EO 13681] y la aplicación debe proporcionar al menos AAL2. Sin embargo, los requisitos de verificación de identidad siguen siendo ambiguos. El proceso de negocio completo de examinar un currículum y, en última instancia, contratar e incorporar a una persona requiere un nivel significativo de verificación de identidad. La agencia necesita un alto nivel de confianza en que el solicitante de empleo es, de hecho, el sujeto del currículum enviado en línea si se toma la decisión de contratarlo. Sin embargo, este nivel de verificación no es necesario para enviar el currículum en línea. La verificación de identidad no es necesaria para completar con éxito la parte digital de la transacción. Verificar la identidad del remitente crearía más riesgo del necesario en el sistema en línea, ya que se recopilaría información personal adicional cuando no es necesaria para la parte del proceso de contratación que cubre el portal digital de solicitudes de empleo, lo que podría reducir la usabilidad. Por lo tanto, la selección más apropiada de IAL sería 1. No hay necesidad de verificar la identidad del usuario para completar con éxito la transacción en línea. Esta decisión para el propio portal en línea es independiente de un requisito aparentemente obvio de verificación de identidad para el proceso de negocio completo, para evitar que se ofrezca un trabajo a un solicitante fraudulento

5.3.2 Impactos por Categoría

Esta sección define los impactos potenciales para cada categoría de daño. Cada nivel de aseguramiento (IAL, AAL, y FAL si se acepta o afirma una identidad federada) DEBE evaluarse por separado.

Nota: Si un error en el sistema de identidad no causa consecuencias medibles para una categoría, no hay impacto.

Impacto potencial de inconveniencia, angustia o daño a la reputación o estatus:

Bajo: En el peor de los casos, una inconveniencia, angustia o vergüenza limitada y a corto plazo para cualquier parte.
Moderado: En el peor de los casos, una inconveniencia, angustia o daño serio a corto plazo o limitado a largo plazo al estatus o reputación de cualquier parte.
Alto: Inconveniencia, angustia o daño severo o grave a largo plazo al estatus o reputación de cualquier parte. Esto se reserva, por lo general, para situaciones con efectos particularmente graves o que potencialmente afectan a muchas personas.

Impacto potencial de pérdida financiera:

Bajo: En el peor de los casos, una pérdida financiera insignificante o inconsecuente para cualquier parte, o en el peor de los casos, una responsabilidad insignificante o inconsecuente para la agencia.
Moderado: En el peor de los casos, una pérdida financiera grave para cualquier parte, o una responsabilidad grave para la agencia.
Alto: Pérdida financiera severa o catastrófica para cualquier parte, o responsabilidad severa o catastrófica para la agencia.

Impacto potencial de daño a los programas de la agencia o a los intereses públicos:

Bajo: En el peor de los casos, un efecto adverso limitado en las operaciones u activos de la organización, o en los intereses públicos. Ejemplos de efectos adversos limitados son: (i) degradación de la capacidad de la misión en la medida y duración en que la organización pueda desempeñar sus funciones principales con una efectividad visiblemente reducida, o (ii) daño menor a los activos de la organización o a los intereses públicos.
Moderado: En el peor de los casos, un efecto adverso grave en las operaciones u activos de la organización, o en los intereses públicos. Ejemplos de efectos adversos graves son: (i) degradación significativa de la capacidad de la misión en la medida y duración en que la organización pueda desempeñar sus funciones principales con una efectividad significativamente reducida, o (ii) daño significativo a los activos de la organización o a los intereses públicos.
Alto: Un efecto adverso severo o catastrófico en las operaciones u activos de la organización, o en los intereses públicos. Ejemplos de efectos graves o catastróficos son: (i) una degradación severa o pérdida de la capacidad de la misión en la medida y duración en que la organización no pueda desempeñar una o más de sus funciones principales, o (ii) un daño mayor a los activos de la organización o a los intereses públicos.

Impacto potencial de la divulgación no autorizada de información sensible:

Bajo: En el peor de los casos, una divulgación limitada de información personal, sensible del gobierno de EE. UU., o comercialmente sensible a partes no autorizadas, lo que resulta en una pérdida de confidencialidad con un impacto bajo, según se define en FIPS 199.
Moderado: En el peor de los casos, una divulgación de información personal, sensible del gobierno de EE. UU., o comercialmente sensible a partes no autorizadas, lo que resulta en una pérdida de confidencialidad con un impacto moderado, según se define en FIPS 199.
Alto: Una divulgación de información personal, sensible del gobierno de EE. UU., o comercialmente sensible a partes no autorizadas, lo que resulta en una pérdida de confidencialidad con un impacto alto, según se define en FIPS 199.

Impacto potencial en la seguridad personal:

Bajo: En el peor de los casos, una lesión menor que no requiere tratamiento médico.
Moderado: En el peor de los casos, un riesgo moderado de lesión menor o un riesgo limitado de lesión que requiera tratamiento médico.
Alto: Un riesgo de lesión grave o muerte.

Impacto potencial de violaciones civiles o penales:

Bajo: En el peor de los casos, un riesgo de violaciones civiles o penales de una naturaleza que normalmente no estaría sujeta a esfuerzos de aplicación.
Moderado: En el peor de los casos, un riesgo de violaciones civiles o penales que podrían estar sujetas a esfuerzos de aplicación.
Alto: Un riesgo de violaciones civiles o penales que son de especial importancia para los programas de aplicación.

5.4 Aceptación de Riesgos y Controles Compensatorios

La suite SP 800-63 especifica requisitos básicos para los servicios de identidad digital basados en el nivel de aseguramiento. Las agencias DEBERÍAN implementar los servicios de identidad de acuerdo con los requisitos de estas directrices y DEBERÍAN considerar técnicas y tecnologías adicionales para asegurar y mejorar la privacidad de sus servicios.

Las agencias PUEDEN determinar alternativas a las recomendaciones de NIST, para los niveles de aseguramiento evaluados (xAL), basándose en su misión, tolerancia al riesgo, procesos de negocio existentes, consideraciones especiales para ciertas poblaciones, disponibilidad de datos que proporcionen mitigaciones similares a las descritas en esta suite, o debido a otras capacidades únicas de la agencia.

Las agencias DEBERÁN demostrar la comparabilidad de cualquier alternativa elegida, incluidos los controles compensatorios, cuando no se implemente el conjunto completo de requisitos aplicables de SP 800-63. Por ejemplo, una agencia puede optar por un perfil de protección del National Information Assurance Partnership (NIAP) en lugar de FIPS, siempre que el perfil sea equivalente o más fuerte que los requisitos de FIPS. Dicho esto, las agencias NO DEBERÁN alterar el nivel de aseguramiento evaluado (xAL) basado en las capacidades de la agencia. En su lugar, la agencia PUEDO ajustar su implementación de soluciones basándose en la capacidad de la agencia para mitigar el riesgo mediante medios no abordados explícitamente por los requisitos de SP 800-63. La agencia DEBERÁ implementar procedimientos para documentar tanto la justificación de cualquier desviación de los requisitos normativos como los controles compensatorios empleados.

Esta guía aborda únicamente los riesgos asociados con errores de autenticación y verificación de identidad. La Publicación Especial de NIST 800-30, Guía de Gestión de Riesgos para Sistemas de Tecnología de la Información [SP 800-30], recomienda una metodología general para gestionar el riesgo en sistemas federales.

5.5 Declaración de Aceptación de Identidad Digital

Las agencias DEBERÍAN incluir esta información en los documentos existentes requeridos para lograr una SA&A (Security Assessment and Authorization).

La declaración DEBERÁ incluir, como mínimo:

xAL evaluado,
xAL implementado,
Razonamiento, si el xAL implementado difiere del xAL evaluado,
Demostración de comparabilidad de los controles compensatorios cuando no se implemente el conjunto completo de requisitos aplicables de 800-63, y
Si no se aceptan identidades federadas, razonamiento.

5.6 Migración de Identidades

A medida que estas directrices se revisen, los CSP (Proveedores de Servicios de Confianza) DEBERÁN considerar cómo los cambios en los requisitos afectan a su población de usuarios. En algunos casos, la población de usuarios no se verá afectada, mientras que en otros, el CSP necesitará que los usuarios lleven a cabo una actividad de transición. Por ejemplo, los CSP pueden solicitar a los usuarios — al iniciar sesión por primera vez desde la última revisión — que proporcionen evidencia adicional de verificación para cumplir con los nuevos requisitos de IAL. Esta DEBERÁ ser una decisión basada en el riesgo, tomada en el contexto del CSP, cualquier RP (Proveedor de Servicios de Registro) que utilice el CSP, la misión y la población a la que se sirve. Las siguientes consideraciones solo sirven como guía para las agencias al considerar los impactos de los cambios en los requisitos:

Si el RP está experimentando fraude relacionado con identidades, una migración puede resultar beneficiosa. Si no es así, la migración puede no aportar valor adicional.
Opciones de autenticación nuevas, más fuertes o más amigables para el usuario añadidas a los AAL individuales pueden llevar a que el CSP emita nuevos autenticadores o permita a los usuarios registrar autenticadores que ya tienen.
Los requisitos de federación pueden o no tener un impacto en el usuario. Por ejemplo, los requisitos de consentimiento o infraestructura podrían exigir una actualización de infraestructura o protocolo.
La adición o eliminación de xALs puede no requerir una migración, pero desencadenaría una nueva evaluación de riesgos para determinar si un cambio es necesario para el RP.

La guía no prescribe que se deba llevar a cabo ninguna migración, solo que se considere a medida que se publiquen las revisiones. Depende del CSP y del RP, basándose en su tolerancia al riesgo y misión, determinar el mejor enfoque.

6 Selección de Niveles de Aseguramiento

Esta sección es normativa.

Los resultados de la evaluación de riesgos son el factor principal en la selección de los niveles más apropiados. Esta sección detalla cómo aplicar los resultados de la evaluación de riesgos junto con factores adicionales no relacionados con el riesgo para determinar la selección de xAL más ventajosa.

Primero, compara el perfil de impacto de la evaluación de riesgos con los perfiles de impacto asociados con cada nivel de aseguramiento, como se muestra en la Tabla 6-1 a continuación. Para determinar el nivel de aseguramiento requerido, encuentra el nivel más bajo cuyo perfil de impacto cumpla o exceda el impacto potencial para cada categoría analizada en la evaluación de riesgos.

Tabla 6-1 Impactos Potenciales Máximos para Cada Nivel de Aseguramiento

	Nivel de seguridad
Categorías de Impacto	1	2	3
Inconveniente, angustia o daño a la reputación	Bajo	Moderado	Alto
Pérdida financiera o responsabilidad de la agencia	Bajo	Moderado	Alto
Daño a programas de la agencia o intereses públicos	N/A	Bajo/Moderado	Alto
Liberación no autorizada de información sensible	N/A	Bajo/Moderado	Alto
Seguridad personal	N/A	Bajo	Moderado/Alto
Violaciones civiles o criminales	N/A	Bajo/Moderado	Alto

En el análisis de riesgos, la agencia DEBERÁ considerar todos los resultados directos e indirectos esperados de una falla de autenticación, incluyendo la posibilidad de que haya más de una falla o daños a más de una persona u organización. Las definiciones de impactos potenciales contienen algunos términos relativos, como "grave" o "menor", cuyo significado dependerá del contexto. La agencia DEBERÁ considerar el contexto y la naturaleza de las personas o entidades afectadas para decidir la importancia relativa de estos daños. Con el tiempo, el significado de estos términos se volverá más definido a medida que las agencias adquieran experiencia práctica con estos problemas. El análisis de daños a programas de la agencia u otros intereses públicos depende en gran medida del contexto; la agencia DEBERÁ considerar estos problemas con cuidado.

Es posible que los niveles de aseguramiento puedan diferir entre IAL, AAL y FAL. Por ejemplo, supongamos que una agencia establece una aplicación de "rastreador de salud" en la que los usuarios envían información personal en forma de información de salud personal (PHI). De acuerdo con los términos del EO 13681 que requieren "que todas las agencias que hacen que los datos personales estén accesibles para los ciudadanos a través de aplicaciones digitales requieran el uso de múltiples factores de autenticación," la agencia está obligada a implementar MFA en AAL2 o AAL3.

El EO 13681 también exige que las agencias empleen "un proceso efectivo de verificación de identidad, según corresponda" cuando se libera información personal. Esto no significa que la verificación en IAL2 o IAL3 (para coincidir con el AAL requerido) sea necesaria. En el ejemplo anterior, puede que no haya necesidad de que el sistema de la agencia conozca la identidad real del usuario. En este caso, un "proceso de verificación efectivo" sería no realizar la verificación en absoluto, por lo que la agencia seleccionaría IAL1. Esto permite que el usuario del sistema de rastreador de salud sea pseudónimo.

A pesar de que el usuario sea pseudónimo, la agencia aún debería seleccionar AAL2 o AAL3 para la autenticación porque un actor malicioso podría obtener acceso a la PHI del usuario al comprometer la cuenta.

Nota: Una agencia puede aceptar un nivel de aseguramiento más alto que los requeridos en la tabla anterior. Por ejemplo, en una transacción federada, una agencia puede aceptar una identidad IAL3 si su aplicación está evaluada en IAL2. Lo mismo se aplica a los autenticadores: se pueden usar autenticadores más fuertes en RPs que tienen requisitos de autenticador más bajos. Sin embargo, los RPs deberán asegurarse de que esto solo ocurra en escenarios federados con las protecciones de privacidad adecuadas por parte del CSP, de manera que solo se proporcionen al RP los atributos que han sido solicitados por el RP y autorizados por el suscriptor, y que no se filtre información personal excesiva desde el credencial o una afirmación. Consulta las consideraciones de privacidad en SP 800-63C para más detalles.

Nota: La consecuencia de tener potencialmente un IAL, AAL y FAL diferentes dentro de una sola aplicación proviene del hecho de que este documento ya no apoya la noción de un LOA general: el enfoque del "mínimo nivel" para determinar el LOA ya no se aplica. Una aplicación con IAL1 y AAL2 no debe considerarse menos segura o de menor privacidad que una aplicación con IAL2 y AAL2. La única diferencia entre estas aplicaciones es la cantidad de verificación requerida, que puede no impactar la seguridad y privacidad de cada aplicación. Dicho esto, si una agencia determina incorrectamente el xAL, la seguridad y privacidad podrían verse afectadas.

6.1 Selección del IAL

El árbol de decisión para el IAL en la Figura 6-1 combina los resultados de la evaluación de riesgos con consideraciones adicionales relacionadas con los servicios de verificación de identidad para permitir a las agencias seleccionar los requisitos de verificación de identidad más apropiados para su oferta de servicios digitales.

La selección del IAL no significa que el proveedor del servicio digital necesite realizar la verificación por sí mismo. Más información sobre si una agencia puede federarse se proporciona en la Sección 7.

El árbol de decisión para el IAL en la Figura 6-1

1 ¿Para proporcionar el servicio, necesita alguna información personal?

La evaluación de riesgos y la selección de IAL pueden ser simplificadas respondiendo primero a esta pregunta: Si el servicio no requiere ninguna información personal para ejecutar transacciones digitales, el sistema puede operar en IAL1.

2 ¿Para completar la transacción, necesita que la información sea validada?

Si se necesita información personal, el RP debe determinar si se requieren atributos validados y verificados, o si son aceptables los atributos autoafirmados. Si se necesita incluso un solo atributo validado y verificado, entonces el proveedor deberá aceptar atributos que hayan sido comprobados en IAL2 o IAL3. Nuevamente, la selección de IAL puede simplificarse a IAL1 si la agencia puede ofrecer el servicio digital solo con atributos autoafirmados.

3 ¿Cuáles son los riesgos (para la organización o el sujeto) de proporcionar el servicio digital?

En este punto, la agencia entiende que se requiere algún nivel de verificación. El paso 3 tiene como objetivo examinar los posibles impactos de una falla en la verificación de identidad para determinar si IAL2 o IAL3 es la selección más adecuada. La principal falla en la verificación de identidad que una agencia puede enfrentar es aceptar una identidad falsificada como verdadera, proporcionando así un servicio o beneficio a la persona equivocada o no elegible. Además, la verificación, cuando no es necesaria, o la recopilación de más información de la necesaria, es un riesgo en sí mismo. Por lo tanto, obtener información de atributos verificados cuando no se necesita también se considera una falla en la verificación de identidad. Este paso debería identificar si la agencia respondió incorrectamente a los Pasos 1 y 2, dándose cuenta de que no necesita información personal para ofrecer el servicio. El riesgo debe considerarse desde la perspectiva de la organización y del usuario, ya que uno puede no verse negativamente afectado mientras que el otro podría sufrir un daño significativo. Los procesos de gestión de riesgos de la agencia deben comenzar con este paso.

4 ¿Necesita resolver una identidad de manera única?

El Paso 4 tiene como objetivo determinar si la información personal requerida por la agencia se resolverá en última instancia en una identidad única. En otras palabras, la agencia necesita conocer la identidad completa del sujeto que accede al servicio digital, y el acceso seudónimo, incluso con algunos atributos validados y verificados, no es posible. Si la agencia necesita identificar de manera única al sujeto, el proceso puede terminar. Sin embargo, la agencia debería considerar si el Paso 5 les resulta útil, ya que la aceptación de declaraciones reducirá la exposición al riesgo de recopilar y almacenar más información personal de la necesaria.

5 ¿Puede aceptar referencias?

El Paso 5 se centra en si el servicio digital puede proporcionarse sin tener acceso a todos los valores de los atributos completos. Esto no significa que todos los atributos deban ser entregados como afirmaciones, pero este paso pide a la agencia que examine cada atributo personal que ha considerado necesario y determine cuáles pueden ser suficientes como afirmaciones y cuáles necesitan ser valores completos. Un entorno federado es el más adecuado para recibir afirmaciones, ya que el proveedor del servicio digital no controla la información de los atributos desde el principio. Si la aplicación también realiza toda la verificación de identidad requerida, las afirmaciones pueden no tener sentido ya que los valores completos ya están bajo el control del proveedor del servicio digital.

6 Utiliza referencias si puedes completar la transacción o ofrecer el servicio sin los valores completos de los atributos.

Si la agencia ha llegado al Paso 6, se deben utilizar afirmaciones. Este paso identifica el servicio digital como un excelente candidato para aceptar referencias de atributos federados de un CSP (o múltiples CSP), ya que se ha determinado que no se necesitan valores completos de atributos para ofrecer el servicio digital..

Nota: Las agencias también deben considerar la demografía de sus usuarios al seleccionar el proceso de verificación más apropiado. Aunque no es una función de la selección de IAL, ciertos procesos de verificación pueden ser más adecuados para algunos grupos demográficos que para otros. Las agencias se beneficiarán de este tipo de análisis, ya que garantiza la mayor oportunidad de que sus usuarios sean verificados con éxito.

6.2 Selección de AAL

El árbol de decisión de AAL en la Figura 6-2 combina los resultados de la evaluación de riesgos con consideraciones adicionales relacionadas con la autenticación para permitir que las agencias seleccionen los requisitos de autenticación más apropiados para su oferta de servicios digitales.

La selección de AAL no significa que el proveedor del servicio digital necesite emitir los autenticadores por sí mismo. Se proporciona más información sobre si la agencia puede federarse en la Sección 7.

Figura 6-2 Selección de AAL

¿Cuáles son los riesgos (para la organización o el sujeto) de proporcionar el servicio digital?

El Paso 1 solicita a las agencias que analicen los posibles impactos de una falla en la autenticación. En otras palabras, ¿qué ocurriría si un usuario no autorizado accediera a una o más cuentas de usuario válidas? El riesgo debe considerarse desde la perspectiva de la organización y del usuario válido, ya que uno puede no verse negativamente afectado mientras que el otro podría sufrir un daño significativo. Los procesos de gestión de riesgos de la agencia deben comenzar con este paso.

¿Estás haciendo accesible la información personal?

Se requiere MFA (autenticación multifactor) cuando cualquier información personal se pone a disposición en línea. Dado que los otros caminos en este árbol de decisión ya llevan a la agencia a un AAL que requiere MFA, la cuestión de la información personal solo se plantea en este punto. Dicho esto, la divulgación de información personal en todos los AALs debe considerarse al realizar la evaluación de riesgos. Un punto importante en este paso es que la recopilación de información personal, si no se pone a disposición en línea, no necesita ser validada o verificada para requerir un AAL de 2 o superior. La divulgación de incluso información personal autoafirmada requiere protección de la cuenta mediante MFA. Aunque la información autoafirmada puede ser falsificada, la mayoría de los usuarios proporcionarán información precisa para beneficiarse del servicio digital. Como tal, los datos autoafirmados deben estar protegidos adecuadamente.

6.3 Selección de FAL

El árbol de decisión de FAL en la Figura 6-3 combina los resultados de la evaluación de riesgos con consideraciones adicionales relacionadas con la federación para permitir que las agencias seleccionen los requisitos más apropiados para su oferta de servicios digitales.

Figura 6-3 Selección de FAL

¿Cuáles son los riesgos (para la organización o el sujeto) de proporcionar el servicio digital?

El Paso 1 solicita a las agencias que analicen los posibles impactos de una falla en la federación. En otras palabras, ¿qué ocurriría si un usuario no autorizado pudiera comprometer una afirmación? Ejemplos de compromiso incluyen el uso de la repetición de afirmaciones para hacerse pasar por un usuario válido o la filtración de información de afirmaciones a través del navegador. El riesgo debe considerarse desde la perspectiva de la organización y del suscriptor, ya que uno puede no verse negativamente afectado mientras que el otro podría sufrir un daño significativo. Los procesos de gestión de riesgos de la agencia deben comenzar con este paso.

¿Estará la información personal en la afirmación?

FAL2 es requerido cuando cualquier información personal se pasa en una afirmación. La liberación de información personal en todos los FALs debe ser considerada al realizar la evaluación de riesgos. Se requiere FAL2 o superior cuando cualquier información personal está contenida en una afirmación, ya que los requisitos de audiencia y cifrado en FAL1 no son suficientes para proteger la información personal de ser divulgada. La liberación incluso de información personal autoafirmada requiere protección de la afirmación mediante FAL2. Aunque la información autoafirmada puede ser falsificada, la mayoría de los usuarios proporcionará información precisa para beneficiarse del servicio digital. Sin embargo, cuando la información personal está disponible para el RP a través de una llamada API autorizada, dicha información no necesita ser incluida en la afirmación en sí. Dado que la afirmación ya no incluye información personal, no necesita ser cifrada y este requisito de FAL no se aplica.

¿Estás utilizando la presentación de afirmaciones a través del canal frontal?

Los RPs deberían utilizar un mecanismo de presentación a través del canal de retroceso, como se describe en SP 800-63C Sección 7.1, siempre que sea posible, ya que estos mecanismos permiten una mayor privacidad y seguridad. Dado que el suscriptor maneja solo una referencia de afirmación y no la afirmación en sí, hay menos posibilidades de que se filtren atributos u otra información sensible contenida en la afirmación al navegador del suscriptor u otros programas. Como el RP presenta directamente la referencia de afirmación al IdP, el IdP a menudo puede tomar medidas para identificar y autenticar al RP durante este paso. Además, dado que el RP obtiene la afirmación directamente del IdP a través de un canal protegido autenticado, hay menos oportunidades para que un atacante inyecte una afirmación en un RP.

Todos los FALs requieren que las afirmaciones tengan un conjunto básico de protecciones, que incluyen firmas, expiraciones, restricciones de audiencia y otras enumeradas en SP 800-63C. Tomadas en conjunto, estas medidas garantizan que las afirmaciones no puedan ser creadas o modificadas por una parte no autorizada, y que un RP no acepte una afirmación creada para un sistema diferente.

6.4 Combinación de xALs

Esta guía introduce un modelo en el que se pueden seleccionar niveles individuales de xAL sin requerir paridad entre ellos. Aunque existen opciones para seleccionar diferentes xALs para un sistema, en muchos casos se elegirá el mismo nivel para todos los xALs.

La capacidad de combinar diferentes xALs ofrece una flexibilidad significativa a las agencias, pero no todas las combinaciones son posibles debido a la naturaleza de los datos recopilados de un individuo y los autenticadores necesarios para proteger esos datos. La Tabla 6-2 detalla las combinaciones válidas de IAL y AAL para asegurar que la información personal permanezca protegida por MFA.

Tabla 6-2 Combinaciones Aceptables de IAL y AAL

	AAL1	AAL2	AAL3
IAL1: Sin datos personales	Permitido	Permitido	Permitido
IAL1: Con datos personales	NO	Permitido	Permitido
IAL2	NO	Permitido	Permitido
IAL3	NO	Permitido	Permitido

Nota: Según la Orden Ejecutiva 13681 [EO 13681], la liberación de datos personales requiere protección con MFA, incluso si los datos personales son autoafirmados y no validados. Cuando la transacción no hace que los datos personales sean accesibles, la autenticación puede realizarse en AAL1, aunque se recomienda proporcionar una opción para que el usuario elija una autenticación más fuerte. Además, puede ser posible en IAL1 autoafirmar información que no sea personal, en cuyo caso AAL1 es aceptable.

7 Consideraciones sobre Federación

Esta sección es informativa.

Esta guía y sus volúmenes complementarios son neutrales respecto a la arquitectura de autenticación y verificación de identidad que una agencia selecciona. Sin embargo, hay escenarios que una agencia puede encontrar en los que la federación de identidad puede ser potencialmente más eficiente y efectiva que establecer servicios de identidad localmente en la agencia o en aplicaciones individuales. La siguiente lista detalla los escenarios en los que, si alguno se aplica, la agencia puede considerar la federación como una opción viable. Esta lista no toma en cuenta los beneficios económicos o las debilidades de la federación frente a arquitecturas de identidad localizadas.

Federar autenticadores cuando:

Los usuarios potenciales ya tienen un autenticador en o por encima del AAL requerido.
Se requieren múltiples formas de credenciales para cubrir todas las posibles comunidades de usuarios.
La agencia no tiene infraestructura para soportar la gestión de autenticación (por ejemplo, recuperación de cuentas, emisión de autenticadores, soporte técnico).
Existe el deseo de permitir que los autenticadores primarios sean añadidos y actualizados con el tiempo sin cambiar la implementación del RP.
Se deben soportar diferentes entornos, ya que los protocolos de federación son basados en red y permiten su implementación en una amplia variedad de plataformas y lenguajes.
Los usuarios potenciales provienen de múltiples comunidades, cada una con su propia infraestructura de identidad existente.

Federar atributos cuando:

Se requiere, es necesario, factible o importante para las partes interesadas acceder al servicio de manera seudónima.
El acceso al servicio solo requiere una lista parcial de atributos.
El acceso al servicio solo requiere al menos una referencia de atributo.
La agencia no es la fuente autorizada o emisora para los atributos requeridos.
Los atributos solo son necesarios temporalmente durante el uso (por ejemplo, para tomar una decisión de acceso), de modo que la agencia no necesita almacenar localmente los datos.

8 Referencias

Esta sección es informativa.

8.1 Referencias Generales

[A-130] Circular A-130 de OMB, Gestión de la Información Federal como un Recurso Estratégico, 28 de julio de 2016, disponible en: https://obamawhitehouse.archives.gov/sites/default/files/omb/assets/OMB/circulars/a130/a130revised.pdf.
[eIDAS] Unión Europea, REGULACIÓN (UE) No 910/2014 DEL PARLAMENTO EUROPEO Y DEL CONSEJO, 23 de julio de 2014, disponible en: http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2014.257.01.0073.01.ENG.
[EO 13681] Orden Ejecutiva 13681, Mejorar la Seguridad de las Transacciones Financieras de los Consumidores, 17 de octubre de 2014, disponible en: https://www.federalregister.gov/d/2014-25439.
[ESIG] Federal CIO Council, Uso de Firmas Electrónicas en Transacciones de Organizaciones Federales, 25 de enero de 2013, disponible en: https://cio.gov/wp-content/uploads/downloads/2014/03/Use_of_ESignatures_in_Federal_Agency_Transactions_v1-0_20130125.pdf.
[FISMA] Ley de Modernización de la Seguridad de la Información Federal de 2014, disponible en: https://www.congress.gov/bill/113th-congress/senate-bill/2521.
[GPG 44] Oficina del Gabinete del Reino Unido, Guía de Buenas Prácticas 44, Autenticación y Credenciales para el Uso de los Servicios en Línea del HMG, 8 de agosto de 2016, disponible en: https://www.ncsc.gov.uk/guidance/authentication-and-credentials-use-hmg-online-services-gpg-44.
[GPG 45] Oficina del Gabinete del Reino Unido, Guía de Buenas Prácticas 45, Verificación de Identidad y Verificación de un Individuo, 3 de noviembre de 2014, disponible en: https://www.gov.uk/government/publications/identity-proofing-and-verification-of-an-individual.
[HSPD-12] Departamento de Seguridad Nacional, Directiva Presidencial de Seguridad Nacional 12: Política para un Estándar de Identificación Común para Empleados y Contratistas Federales, 27 de agosto de 2004, disponible en: https://www.dhs.gov/homeland-security-presidential-directive-12.
[M-03-22] Memorándum M-03-22 de OMB, Guía de OMB para la Implementación de las Disposiciones de Privacidad de la Ley de Gobierno Electrónico de 2002, 26 de septiembre de 2003, disponible en: https://georgewbush-whitehouse.archives.gov/omb/memoranda/m03-22.html.
[M-04-04] Memorándum M-04-04 de OMB, Guía de Autenticación Electrónica para Agencias Federales, 16 de diciembre de 2003, disponible en: https://georgewbush-whitehouse.archives.gov/omb/memoranda/fy04/m04-04.pdf.
[NSTIC] Estrategia Nacional para Identidades de Confianza en el Ciberespacio, abril de 2011, disponible en: https://www.nist.gov/sites/default/files/documents/2016/12/08/nsticstrategy.pdf.
[NISTIR8062] Informe Interno de NIST 8062, Introducción a la Ingeniería de Privacidad y Gestión de Riesgos en Sistemas Federales, enero de 2017, disponible en: http://nvlpubs.nist.gov/nistpubs/ir/2017/NIST.IR.8062.pdf.
[NIST RMF] Descripción General del Marco de Gestión de Riesgos, disponible en: http://csrc.nist.gov/groups/SMA/fisma/framework.html.
[RSDOPS] Oficina del Gabinete del Reino Unido, Guía de Buenas Prácticas 43, Requisitos para la Entrega Segura de Servicios Públicos en Línea (RSDOPS), 3 de noviembre de 2014, disponible en: https://www.gov.uk/government/publications/requirements-for-secure-delivery-of-online-public-services.
[Steiner] Steiner, Peter. “En Internet, nadie sabe que eres un perro”, The New Yorker, 5 de julio de 1993.
[STORK 2.0] Unión Europea, Secure idenTity acrOss boRders linKed 2.0, 2014, disponible en: https://www.eid-stork2.eu/.

8.2 Normas

[BCP 195] Sheffer, Y., Holz, R., y P. Saint-Andre, Recomendaciones para el Uso Seguro de Transport Layer Security (TLS) y Datagram Transport Layer Security (DTLS), BCP 195, RFC 7525, DOI 10.17487/RFC7525, mayo de 2015, https://doi.org/10.17487/RFC7525.
[Canada] Gobierno de Canadá, Estándar sobre Aseguramiento de Identidad y Credenciales, 1 de febrero de 2013, disponible en: https://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=26776.
[ISO 9241-11] Organización Internacional de Normalización, ISO/IEC 9241-11 Requisitos ergonómicos para el trabajo de oficina con terminales de visualización (VDTs) — Parte 11: Guía sobre usabilidad, marzo de 1998, disponible en: https://www.iso.org/standard/16883.html.
[ISO 29003] Organización Internacional de Normalización, ISO/IEC DTS 29003 Tecnología de la información — Técnicas de seguridad — Verificación de identidad.
[ISO 29115] Organización Internacional de Normalización, ISO/IEC 29115 Tecnología de la información — Técnicas de seguridad — Marco de aseguramiento de autenticación de entidades, 1 de abril de 2013, disponible en: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=45138.
[OIDC] Sakimura, N., Bradley, B., Jones, M., de Medeiros, B., y C. Mortimore, OpenID Connect Core 1.0 incorporando el conjunto de erratas 1, noviembre de 2014, disponible en: https://openid.net/specs/openid-connect-core-1_0.html.

8.3 Publicaciones Especiales de NIST

Las publicaciones especiales de la serie 800 de NIST están disponibles en:

http://csrc.nist.gov/publications/nistpubs/index.html. Las siguientes publicaciones pueden ser de particular interés para quienes implementan sistemas de aplicaciones que requieren autenticación digital.

[SP 800-30] Publicación Especial de NIST 800-30 Revisión 1, Guía para la Realización de Evaluaciones de Riesgos, septiembre de 2012, https://doi.org/10.6028/NIST.SP.800-30r1.
[SP 800-37] Publicación Especial de NIST 800-37 Revisión 1, Guía para la Aplicación del Marco de Gestión de Riesgos a los Sistemas de Información Federales, Enfoque del Ciclo de Vida de Seguridad, febrero de 2010 (actualizado el 5 de junio de 2014), https://doi.org/10.6028/NIST.SP.800-37r1.
[SP 800-52] Publicación Especial de NIST 800-52 Revisión 1, *Directrices para la Selección, Configuración y Uso de Implementaciones de Transport Layer Security (TLS), abril de 2014, http://dx.doi.org/10.6028/NIST.SP.800-52r1.
[SP 800-53A] Publicación Especial de NIST 800-53A Revisión 4, Evaluación de Controles de Seguridad y Privacidad en Sistemas y Organizaciones Federales de Información, Elaboración de Planes de Evaluación Efectivos, diciembre de 2014 (actualizado el 18 de diciembre de 2014), https://doi.org/10.6028/NIST.SP.800-53Ar4.

8.4 Normas de Procesamiento de Información Federal

[FIPS 199] Norma Federal de Procesamiento de Información 199, Estándares para la Categorización de Seguridad de la Información y los Sistemas de Información Federales, febrero de 2004, https://doi.org/10.6028/NIST.FIPS.199.
[FIPS 201] Publicación de Norma Federal de Procesamiento de Información 201-2, Verificación de Identidad Personal (PIV) de Empleados y Contratistas Federales, agosto de 2013, http://dx.doi.org/10.6028/NIST.FIPS.201-2.

Apéndice A—Definiciones y Abreviaturas

Esta sección es normativa.

A.1 Definiciones

Se utiliza una amplia variedad de términos en el ámbito de la autenticación. Aunque muchas definiciones de los términos son consistentes con versiones anteriores del SP 800-63, algunas han cambiado en esta revisión. Muchos de estos términos carecen de una definición única y consistente, por lo que se debe prestar especial atención a cómo se definen aquí.

Acceso

Contactar con una o más funciones discretas de un servicio digital en línea.

Ataque Activo

Un ataque al protocolo de autenticación en el que el atacante transmite datos al solicitante, al Proveedor de Servicios de Credenciales (CSP), al verificador o a la Parte Receptora (RP). Ejemplos de ataques activos incluyen el hombre en el medio (MitM), la suplantación y el secuestro de sesión.

Dirección de Registro

La ubicación validada y verificada (física o digital) donde un individuo puede recibir comunicaciones utilizando mecanismos aprobados.

Solicitante

Un sujeto que está pasando por los procesos de inscripción y verificación de identidad.

Criptografía Aprobada

Estándar Federal de Procesamiento de Información (FIPS) aprobado o recomendado por NIST. Un algoritmo o técnica que es 1) especificado en un FIPS o Recomendación NIST, o 2) adoptado en un FIPS o Recomendación NIST.

Aserción

Una declaración de un verificador a una RP que contiene información sobre un suscriptor. Las aserciones también pueden contener atributos verificados.

Referencia de Aserción

Un objeto de datos, creado junto con una aserción, que identifica al verificador e incluye un enlace a la aserción completa en poder del verificador.

Claves Asimétricas

Dos claves relacionadas, compuestas por una clave pública y una clave privada, que se utilizan para realizar operaciones complementarias como cifrado y descifrado o verificación y generación de firmas.

Ataque

El intento de una entidad no autorizada de engañar a un verificador o a una RP para que crean que la persona no autorizada es el suscriptor.

Atacante

Una parte, incluida una interna, que actúa con intención maliciosa para comprometer un sistema.

Atributo

Una cualidad o característica atribuida a alguien o algo.

Conjunto de Atributos

Un conjunto empaquetado de atributos, generalmente contenidos dentro de una aserción. Los conjuntos de atributos ofrecen a las RP una forma sencilla de recuperar los atributos más relevantes que necesitan de los IdP. Los conjuntos de atributos son sinónimos de alcances de OpenID Connect [OpenID Connect Core 1.0].

Referencia de Atributo

Una declaración que afirma una propiedad de un suscriptor sin contener necesariamente información de identidad, independientemente del formato. Por ejemplo, para el atributo "fecha de nacimiento", una referencia podría ser "mayor de 18 años" o "nacido en diciembre".

Valor de Atributo

Una declaración completa que afirma una propiedad de un suscriptor, independientemente del formato. Por ejemplo, para el atributo "fecha de nacimiento", un valor podría ser "01/12/1980" o "1 de diciembre de 1980".

Autenticar

Ver Autenticación.

Canal Protegido Autenticado

Un canal de comunicación cifrado que utiliza criptografía aprobada en el que el iniciador de la conexión (cliente) ha autenticado al destinatario (servidor). Los canales protegidos autenticados proporcionan confidencialidad y protección contra MitM y se utilizan frecuentemente en el proceso de autenticación del usuario. La Seguridad de la Capa de Transporte (TLS) [BCP 195] es un ejemplo de un canal protegido autenticado en el que el certificado presentado por el destinatario es verificado por el iniciador. A menos que se especifique lo contrario, los canales protegidos autenticados no requieren que el servidor autentique al cliente. La autenticación del servidor se realiza a menudo a través de una cadena de certificados que lleva a una raíz de confianza en lugar de individualmente con cada servidor.

Autenticación

Verificación de la identidad de un usuario, proceso o dispositivo, a menudo como un requisito previo para permitir el acceso a los recursos de un sistema.

Factor de Autenticación

Los tres tipos de factores de autenticación son algo que sabes, algo que tienes y algo que eres. Cada autenticador tiene uno o más factores de autenticación.

Intención de Autenticación

El proceso de confirmar la intención del solicitante de autenticarse o reautenticarse mediante la inclusión de un proceso que requiera la intervención del usuario en el flujo de autenticación. Algunos autenticadores (p. ej., dispositivos OTP) establecen la intención de autenticación como parte de su funcionamiento, otros requieren un paso específico, como presionar un botón, para establecer la intención. La intención de autenticación es una contramedida contra el uso de malware del punto final como un proxy para autenticar a un atacante sin el conocimiento del suscriptor.

Protocolo de Autenticación

Una secuencia definida de mensajes entre un solicitante y un verificador que demuestra que el solicitante tiene posesión y control de uno o más autenticadores válidos para establecer su identidad, y, opcionalmente, demuestra que el solicitante se está comunicando con el verificador previsto.

Ejecución del Protocolo de Autenticación

Un intercambio de mensajes entre un solicitante y un verificador que resulta en autenticación (o fallo de autenticación) entre las dos partes.

Secreto de Autenticación

Un término genérico para cualquier valor secreto que un atacante podría usar para hacerse pasar por el suscriptor en un protocolo de autenticación.

Estos se dividen en secretos de autenticación a corto plazo, que solo son útiles para un atacante durante un período de tiempo limitado, y secretos de autenticación a largo plazo, que permiten a un atacante hacerse pasar por el suscriptor hasta que se restablecen manualmente. El secreto del autenticador es el ejemplo canónico de un secreto de autenticación a largo plazo, mientras que la salida del autenticador, si es diferente del secreto del autenticador, suele ser un secreto de autenticación a corto plazo.

Autenticador

Algo que el solicitante posee y controla (generalmente un módulo criptográfico o una contraseña) que se usa para autenticar la identidad del solicitante. En ediciones anteriores de SP 800-63, esto se denominaba un token.

Nivel de Garantía del Autenticador (AAL)

Una categoría que describe la fortaleza del proceso de autenticación.

Salida del Autenticador

El valor de salida generado por un autenticador. La capacidad de generar salidas de autenticador válidas bajo demanda demuestra que el solicitante posee y controla el autenticador. Los mensajes de protocolo enviados al verificador dependen de la salida del autenticador, pero pueden o no contenerla explícitamente.

Secreto del Autenticador

El valor secreto contenido dentro de un autenticador.

Tipo de Autenticador

Una categoría de autenticadores con características comunes. Algunos tipos de autenticadores proporcionan un factor de autenticación, otros proporcionan dos.

Autenticidad

La propiedad de que los datos se originaron en su fuente pretendida.

Fuente Autoritativa

Una entidad que tiene acceso a, o copias verificadas de, información precisa de una fuente emisora de tal manera que un CSP puede confirmar la validez de la evidencia de identidad proporcionada por un solicitante durante la verificación de identidad. Una fuente emisora también puede ser una fuente autorizada. A menudo, las fuentes autoritativas son determinadas por una decisión de política de la agencia o CSP antes de que puedan ser utilizadas en la fase de validación de la verificación de identidad.

Componente de Autorización

Algo emitido a una RP por un IdP durante una transacción de federación de identidad que otorga a la RP acceso autorizado a un conjunto de API (por ejemplo, un token de acceso OAuth). Esta credencial puede ser independiente de la aserción proporcionada por el protocolo de federación (por ejemplo, un OpenID Connect ID Token).

Autorizar

Una decisión de otorgar acceso, típicamente automatizada mediante la evaluación de los atributos de un sujeto.

Comunicación de Canal Secundario

Comunicación entre dos sistemas que depende de una conexión directa (permitiendo proxies a nivel de protocolo estándar), sin utilizar redireccionamientos a través de un intermediario como un navegador. Esto se puede lograr mediante solicitudes y respuestas HTTP.

Aserción Portadora

La aserción que una parte presenta como prueba de identidad, donde la posesión de la propia aserción es prueba suficiente de identidad para el portador de la aserción.

Vinculación

Una asociación entre la identidad de un suscriptor y un autenticador o sesión de suscriptor dada.

Biometría

Reconocimiento automatizado de individuos basado en sus características biológicas y de comportamiento.

Protocolo de Desafío-Respuesta

Un protocolo de autenticación en el que el verificador envía al solicitante un desafío (generalmente un valor aleatorio o nonce) que el solicitante combina con un secreto (como mediante el hash del desafío y un secreto compartido, o aplicando una operación de clave privada al desafío) para generar una respuesta que se envía al verificador. El verificador puede verificar independientemente la respuesta generada por el solicitante (como volviendo a calcular el hash del desafío y el secreto compartido y comparándolo con la respuesta, o realizando una operación de clave pública sobre la respuesta).

Reclamante

Un sujeto cuya identidad debe ser verificada utilizando uno o más protocolos de autenticación.

Identidad Reclamada

La declaración de un solicitante sobre atributos personales no validados ni verificados.

Prueba de Turing Pública y Completamente Automatizada para Diferenciar Computadoras de Humanos (CAPTCHA)

Una característica interactiva añadida a los formularios web para distinguir si un humano o un agente automatizado está utilizando el formulario. Típicamente, requiere ingresar un texto que corresponde a una imagen distorsionada o a una secuencia de sonido.

Credencial

Un objeto o estructura de datos que vincula autoritativamente una identidad, a través de un identificador o identificadores, y (opcionalmente) atributos adicionales, con al menos un autenticador poseído y controlado por un suscriptor.

Aunque el uso común a menudo asume que el suscriptor mantiene la credencial, estas directrices también usan el término para referirse a los registros electrónicos mantenidos por el Proveedor de Servicios de Credenciales (CSP, por sus siglas en inglés) que establecen la vinculación entre el(los) autenticador(es) del suscriptor y su identidad.

Proveedor de Servicios de Credenciales (CSP)

Una entidad de confianza que emite o registra los autenticadores de los suscriptores y emite credenciales electrónicas a los suscriptores. Un CSP puede ser una tercera parte independiente o emitir credenciales para su propio uso.

Falsificación de Solicitudes entre Sitios (CSRF)

Un ataque en el que un suscriptor, actualmente autenticado en un Proveedor de Recursos (RP) y conectado a través de una sesión segura, navega hacia un sitio web del atacante, causando que el suscriptor invoque involuntariamente acciones no deseadas en el RP.

Por ejemplo, si el sitio web de un banco es vulnerable a un ataque CSRF, es posible que un suscriptor autorice sin querer una gran transferencia de dinero, simplemente al visualizar un enlace malicioso en un mensaje de correo web mientras tiene abierta una conexión con el banco en otra ventana del navegador.

Secuencias de Comandos entre Sitios (XSS)

Una vulnerabilidad que permite a los atacantes inyectar código malicioso en un sitio web que de otro modo sería benigno. Estos scripts adquieren los permisos de los scripts generados por el sitio web objetivo y, por lo tanto, pueden comprometer la confidencialidad e integridad de las transferencias de datos entre el sitio web y el cliente. Los sitios web son vulnerables si muestran datos suministrados por los usuarios en solicitudes o formularios sin sanear los datos para que no sean ejecutables.

Autenticador Criptográfico

Un autenticador donde el secreto es una clave criptográfica.

Clave Criptográfica

Un valor utilizado para controlar operaciones criptográficas, como desencriptación, encriptación, generación de firmas o verificación de firmas. A efectos de estas directrices, los requisitos de las claves deben cumplir con los requisitos mínimos establecidos en la Tabla 2 de NIST SP 800-57 Parte 1.

Véase también Claves Asimétricas, Clave Simétrica.

Módulo Criptográfico

Un conjunto de hardware, software y/o firmware que implementa funciones de seguridad aprobadas (incluidos algoritmos criptográficos y generación de claves).

Integridad de Datos

La propiedad de que los datos no han sido alterados por una entidad no autorizada.

Credencial Derivada

Una credencial emitida en base a la prueba de posesión y control de un autenticador asociado con una credencial previamente emitida, para no duplicar el proceso de prueba de identidad.

Autenticación Digital

El proceso de establecer confianza en identidades de usuarios presentadas digitalmente a un sistema. En ediciones anteriores de SP 800-63, esto se denominaba Autenticación Electrónica.

Firma Digital

Una operación de clave asimétrica en la que se utiliza la clave privada para firmar digitalmente los datos y la clave pública para verificar la firma. Las firmas digitales proporcionan protección de autenticidad, protección de integridad y no repudio, pero no protección de confidencialidad.

Disociabilidad

Según NISTIR 8062: Habilitar el procesamiento de información personal identificable (PII) o eventos sin asociación a individuos o dispositivos más allá de los requisitos operacionales del sistema.

Diversionaria

En lo que respecta a KBV, una pregunta de opción múltiple para la cual todas las respuestas proporcionadas son incorrectas, lo que requiere que el solicitante seleccione una opción similar a "ninguna de las anteriores".

Ataque de Interceptación (Eavesdropping)

Un ataque en el que un atacante escucha pasivamente el protocolo de autenticación para capturar información que puede ser utilizada en un ataque activo posterior para hacerse pasar por el reclamante.

Autenticación Electrónica (E-Authentication)

Véase Autenticación Digital.

Inscripción

El proceso a través del cual un solicitante solicita convertirse en suscriptor de un CSP y el CSP valida la identidad del solicitante.

Entropía

Una medida de la cantidad de incertidumbre que enfrenta un atacante para determinar el valor de un secreto. La entropía generalmente se expresa en bits. Un valor que tiene n bits de entropía tiene el mismo grado de incertidumbre que un valor aleatorio de n bits distribuido uniformemente.

Norma Federal de Procesamiento de Información (FIPS)

Bajo la Ley de Reforma de la Gestión de Tecnologías de la Información (Ley Pública 104-106), el Secretario de Comercio aprueba las normas y directrices que el Instituto Nacional de Estándares y Tecnología (NIST) desarrolla para los sistemas informáticos federales. El NIST emite estas normas y directrices como Normas Federales de Procesamiento de Información (FIPS) para uso en toda la administración gubernamental. El NIST desarrolla los FIPS cuando existen requisitos federales imperiosos, como para la seguridad y la interoperabilidad, y no existen normas o soluciones industriales aceptables. Consulta la información de fondo para más detalles.

Los documentos FIPS están disponibles en línea en la página principal de FIPS: http://www.nist.gov/itl/fips.cfm

Federación

Un proceso que permite la transmisión de información de identidad y autenticación a través de un conjunto de sistemas en red.

Nivel de Aseguramiento de Federación (FAL)

Una categoría que describe el protocolo de aserción utilizado por la federación para comunicar información de autenticación y atributos (si corresponde) a un Proveedor de Recursos (RP).

Proxy de Federación

Un componente que actúa como un RP lógico para un conjunto de Proveedores de Identidad (IdPs) y como un IdP lógico para un conjunto de RPs, uniendo los dos sistemas con un único componente. A veces se les denomina “intermediarios”.

Comunicación por Canal Frontal

Comunicación entre dos sistemas que se basa en redirecciones a través de un intermediario, como un navegador. Esto normalmente se realiza agregando parámetros de consulta HTTP a las URL alojadas por el receptor del mensaje.

Función Hash

Una función que mapea una cadena de bits de longitud arbitraria a una cadena de bits de longitud fija. Las funciones hash aprobadas deben cumplir con las siguientes propiedades:

Unidireccional: Es computacionalmente inviable encontrar cualquier entrada que mapee a una salida preespecificada; y
Resistente a Colisiones: Es computacionalmente inviable encontrar dos entradas distintas que mapeen a la misma salida.

Identidad

Un atributo o conjunto de atributos que describe de manera única a un sujeto dentro de un contexto dado.

Nivel de Aseguramiento de Identidad (IAL)

Una categoría que transmite el grado de confianza de que la identidad reclamada por el solicitante es su verdadera identidad.

Evidencia de Identidad

Información o documentación proporcionada por el solicitante para apoyar la identidad reclamada. La evidencia de identidad puede ser física (por ejemplo, una licencia de conducir) o digital (por ejemplo, una aserción generada y emitida por un CSP basada en la autenticación exitosa del solicitante con el CSP).

Prueba de Identidad

El proceso mediante el cual un CSP recopila, valida y verifica información sobre una persona.

Proveedor de Identidad (IdP)

La parte que gestiona las credenciales de autenticación primaria del suscriptor y emite aserciones derivadas de esas credenciales. Comúnmente, este es el CSP como se discute en este conjunto de documentos.

Fuente de Emisión

Una autoridad responsable de la generación de datos, evidencia digital (como aserciones) o documentos físicos que pueden usarse como evidencia de identidad.

Kerberos

Un protocolo de autenticación ampliamente utilizado desarrollado en el MIT. En el Kerberos “clásico”, los usuarios comparten una contraseña secreta con un Centro de Distribución de Claves (KDC). El usuario (Alice) que desea comunicarse con otro usuario (Bob) se autentica con el KDC y el KDC proporciona un “boleto” para usar para autenticar con Bob.

Consulta la Sección 11.2 de SP 800-63C para obtener más información.

Verificación Basada en Conocimiento (KBV)

Método de verificación de identidad basado en el conocimiento de información privada asociada con la identidad reclamada. Esto a menudo se denomina autenticación basada en conocimiento (KBA) o prueba basada en conocimiento (KBP).

Gestionabilidad

Según NISTIR 8062: Proporcionar la capacidad para la administración granular de la información personal identificable, incluyendo alteración, eliminación y divulgación selectiva.

Ataque de Hombre en el Medio (MitM)

Un ataque en el que un atacante se posiciona entre dos partes que están comunicándose con el fin de interceptar y/o alterar los datos que viajan entre ellas. En el contexto de la autenticación, el atacante estaría posicionado entre el reclamante y el verificador, entre el registrante y el CSP durante la inscripción, o entre el suscriptor y el CSP durante la vinculación del autenticador.

Secreto Memoriza

Un tipo de autenticador compuesto por una cadena de caracteres destinada a ser memorizada o memorable por el suscriptor, permitiendo al suscriptor demostrar algo que sabe como parte de un proceso de autenticación.

Código de Autenticación de Mensajes (MAC)

Un checksum criptográfico sobre datos que utiliza una clave simétrica para detectar tanto modificaciones accidentales como intencionales de los datos. Los MAC proporcionan protección de autenticidad e integridad, pero no protección contra el no repudio.

Código Móvil

Código ejecutable que normalmente se transfiere desde su fuente a otro sistema informático para su ejecución. Esta transferencia a menudo ocurre a través de la red (por ejemplo, JavaScript incrustado en una página web) pero también puede transferirse a través de medios físicos.

Factor múltiple

Una característica de un sistema de autenticación o de un autenticador que requiere más de un factor de autenticación distinto para una autenticación exitosa. La MFA (Autenticación Multifactorial) puede realizarse utilizando un único autenticador que proporcione más de un factor o mediante una combinación de autenticadores que proporcionen diferentes factores.

Los tres factores de autenticación son: algo que sabes, algo que tienes y algo que eres.

Autenticación de factor múltiple (MFA)

Un sistema de autenticación que requiere más de un factor de autenticación distinto para una autenticación exitosa. La autenticación multifactorial puede realizarse utilizando un autenticador multifactorial o mediante una combinación de autenticadores que proporcionen diferentes factores.

Los tres factores de autenticación son: algo que sabes, algo que tienes y algo que eres.

Autenticador de factor múltiple

Un autenticador que proporciona más de un factor de autenticación distinto, como un dispositivo de autenticación criptográfica con un sensor biométrico integrado que es necesario para activar el dispositivo.

Red

Un medio de comunicación abierto, típicamente Internet, utilizado para transportar mensajes entre el reclamante y otras partes. A menos que se indique lo contrario, no se hacen suposiciones sobre la seguridad de la red; se asume que es abierta y está sujeta a ataques activos (por ejemplo, suplantación de identidad, hombre en el medio, secuestro de sesión) y pasivos (por ejemplo, interceptación) en cualquier punto entre las partes (por ejemplo, reclamante, verificador, CSP, RP).

Número de un solo uso (Nonce)

Un valor utilizado en protocolos de seguridad que nunca se repite con la misma clave. Por ejemplo, los nonces utilizados como desafíos en los protocolos de autenticación de desafío-respuesta NO DEBERÁN repetirse hasta que se cambien las claves de autenticación. De lo contrario, existe la posibilidad de un ataque de reproducción. Utilizar un nonce como desafío es un requisito diferente al de un desafío aleatorio, porque un nonce no es necesariamente impredecible.

Ataque Offline

Un ataque en el que el atacante obtiene algunos datos (típicamente al interceptar un protocolo de autenticación o al penetrar en un sistema y robar archivos de seguridad) que puede analizar en un sistema de su propia elección.

Ataque Online

Un ataque contra un protocolo de autenticación en el que el atacante asume el rol de un reclamante con un verificador genuino o altera activamente el canal de autenticación.

Ataque de Adivinanza en Línea

Un ataque en el que un atacante realiza intentos de inicio de sesión repetidos adivinando posibles valores de la salida del autenticador.

Identificador Pseudónimo Par a Par

Un identificador opaco e inadivinable generado por un Proveedor de Servicios de Comunicación (CSP) para su uso en un Proveedor de Servicios (RP) específico. Este identificador solo es conocido y utilizado por un par CSP-RP.

Ataque Pasivo

Un ataque contra un protocolo de autenticación en el que el atacante intercepta datos que viajan a lo largo de la red entre el solicitante y el verificador, pero no altera los datos (es decir, espionaje).

Frase Secreta

Una frase secreta es un secreto memorizado que consiste en una secuencia de palabras u otro texto que un solicitante usa para autenticar su identidad. Una frase secreta es similar a una contraseña en su uso, pero generalmente es más larga para mayor seguridad.

Contraseña

Ver secreto memorizado.

Datos Personales

Ver Información de Identificación Personal.

Número de Identificación Personal (PIN)

Un secreto memorizado que generalmente consta solo de dígitos decimales.

Información Personal

Ver Información de Identificación Personal.

Información de Identificación Personal (PII)

Según lo definido por la Circular A-130 de la OMB, la Información de Identificación Personal es información que se puede utilizar para distinguir o rastrear la identidad de un individuo, ya sea sola o combinada con otra información que esté vinculada o pueda vincularse a un individuo específico.

Pharming

Un ataque en el que un atacante corrompe un servicio de infraestructura como el DNS (Sistema de Nombres de Dominio), haciendo que el suscriptor sea redirigido a un verificador/RP falso, lo que podría causar que el suscriptor revele información sensible, descargue software dañino o contribuya a un acto fraudulento.

Phishing

Un ataque en el que el suscriptor es engañado (generalmente a través de un correo electrónico) para interactuar con un verificador/RP falso y es inducido a revelar información que se puede usar para hacerse pasar por ese suscriptor ante el verificador/RP real.

Posesión y Control de un Autenticador

La capacidad de activar y usar el autenticador en un protocolo de autenticación.

Declaración de Prácticas

Una declaración formal de las prácticas seguidas por las partes en un proceso de autenticación (por ejemplo, CSP o verificador). Generalmente describe las políticas y prácticas de las partes y puede llegar a ser legalmente vinculante.

Previsibilidad

Según NISTIR 8062: Habilitar suposiciones confiables por parte de individuos, propietarios y operadores sobre la PII y su procesamiento por un sistema de información.

Credenciales Privadas

Credenciales que no pueden ser divulgadas por el CSP porque su contenido puede ser utilizado para comprometer el autenticador.

Clave Privada

La parte secreta de un par de claves asimétricas que se utiliza para firmar digitalmente o descifrar datos.

Procesamiento

Según NISTIR 8062: Operación o conjunto de operaciones realizadas sobre PII que pueden incluir, pero no se limitan a, la recopilación, retención, registro, generación, transformación, uso, divulgación, transferencia y eliminación de PII.

Ataque de Presentación

Presentación al subsistema de captura de datos biométricos con el objetivo de interferir en el funcionamiento del sistema biométrico.

Detección de Ataque de Presentación (PAD)

Determinación automatizada de un ataque de presentación. Un subconjunto de los métodos de determinación de ataque de presentación, conocidos como detección de vitalidad, involucran la medición y análisis de características anatómicas o reacciones involuntarias o voluntarias, con el fin de determinar si una muestra biométrica está siendo capturada de un sujeto vivo presente en el punto de captura.

Sesión Protegida

Una sesión en la que los mensajes entre dos participantes están cifrados y su integridad está protegida utilizando un conjunto de secretos compartidos llamados claves de sesión.

Se dice que un participante está autenticado si, durante la sesión, demuestra la posesión de uno o más autenticadores además de las claves de sesión, y si la otra parte puede verificar la identidad asociada con el(los) autenticador(es). Si ambos participantes están autenticados, se dice que la sesión protegida está autenticada mutuamente.

Seudónimo

Un nombre que no es el nombre legal.

Seudonimia

El uso de un seudónimo para identificar a un sujeto.

Identificador Pseudónimo

Un número único pero sin significado que no permite que el Proveedor de Recursos (RP) infiera nada sobre el suscriptor, pero que sí permite al RP asociar múltiples interacciones con la identidad reclamada del suscriptor.

Credenciales Públicas

Credenciales que describen la vinculación de una manera que no compromete el autenticador.

Clave Pública

La parte pública de un par de claves asimétricas que se usa para verificar firmas o cifrar datos.

Certificado de Clave Pública

Un documento digital emitido y firmado digitalmente por la clave privada de una autoridad certificadora que vincula un identificador a un suscriptor de una clave pública. El certificado indica que el suscriptor identificado en el certificado tiene control y acceso exclusivo a la clave privada. Ver también [RFC 5280].

Infraestructura de Clave Pública (PKI)

Un conjunto de políticas, procesos, plataformas de servidor, software y estaciones de trabajo utilizados para la administración de certificados y pares de claves públicas-privadas, incluyendo la capacidad de emitir, mantener y revocar certificados de clave pública.

Reautenticación

El proceso de confirmar la presencia continua del suscriptor y la intención de ser autenticado durante una sesión de uso prolongada.

Registro

Ver Inscripción.

Parte Confiante (RP)

Una entidad que confía en el(los) autenticador(es) y credenciales del suscriptor o en la afirmación de un verificador sobre la identidad de un reclamante, generalmente para procesar una transacción o otorgar acceso a información o a un sistema.

Remoto

(En el contexto de la autenticación remota o transacción remota) Un intercambio de información entre dispositivos conectados a la red donde la información no puede ser protegida de manera confiable de extremo a extremo por los controles de seguridad de una sola organización.

Ataque de Repetición

Un ataque en el que el atacante es capaz de repetir mensajes previamente capturados (entre un reclamante legítimo y un verificador) para hacerse pasar por ese reclamante ante el verificador o viceversa.

Resistencia a la Repetición

La propiedad de un proceso de autenticación para resistir ataques de repetición, generalmente mediante el uso de una salida del autenticador que es válida solo para una autenticación específica.

Restringido

Un tipo, clase o instancia de autenticador que tiene un riesgo adicional de aceptación falsa asociado con su uso, y por lo tanto está sujeto a requisitos adicionales.

Evaluación de Riesgo

El proceso de identificar, estimar y priorizar los riesgos para las operaciones organizacionales (incluyendo misión, funciones, imagen o reputación), activos organizacionales, individuos y otras organizaciones, que resultan de la operación de un sistema. Es parte de la gestión de riesgos, incorpora análisis de amenazas y vulnerabilidades, y considera las mitigaciones proporcionadas por los controles de seguridad planificados o en funcionamiento. Sinónimo de análisis de riesgo.

Gestión de Riesgos

El programa y los procesos de apoyo para gestionar el riesgo de seguridad de la información para las operaciones organizacionales (incluyendo misión, funciones, imagen, reputación), activos organizacionales, individuos, otras organizaciones, e incluye: (i) establecer el contexto para las actividades relacionadas con el riesgo; (ii) evaluar el riesgo; (iii) responder al riesgo una vez determinado; y (iv) monitorear el riesgo a lo largo del tiempo.

Sal

Un valor no secreto utilizado en un proceso criptográfico, generalmente para asegurar que los resultados de los cálculos para una instancia no puedan ser reutilizados por un atacante.

Capa de Conexión Segura (SSL)

Ver Seguridad de la Capa de Transporte (TLS).

Sesión

Una interacción persistente entre un suscriptor y un punto final, ya sea un RP o un CSP. Una sesión comienza con un evento de autenticación y termina con un evento de terminación de sesión. Una sesión está vinculada mediante el uso de un secreto de sesión que el software del suscriptor (un navegador, aplicación o sistema operativo) puede presentar al RP o CSP en lugar de las credenciales de autenticación del suscriptor.

Ataque de Secuestro de Sesión

Un ataque en el que el atacante es capaz de insertarse entre un reclamante y un verificador después de un intercambio de autenticación exitoso entre las dos últimas partes. El atacante es capaz de hacerse pasar por un suscriptor ante el verificador o viceversa para controlar el intercambio de datos de la sesión. Las sesiones entre el reclamante y el RP pueden ser comprometidas de manera similar.

Secreto Compartido

Un secreto utilizado en la autenticación que es conocido tanto por el suscriptor como por el verificador.

Ataque de Canal Lateral

Un ataque habilitado por la filtración de información desde un sistema criptográfico físico. Las características que podrían ser explotadas en un ataque de canal lateral incluyen el tiempo, el consumo de energía, y las emisiones electromagnéticas y acústicas.

Factor Único

Una característica de un sistema de autenticación o de un autenticador que requiere solo un factor de autenticación (algo que sabes, algo que tienes o algo que eres) para una autenticación exitosa.

Ingeniería Social

El acto de engañar a una persona para que revele información sensible, obtenga acceso no autorizado o cometa fraude, asociándose con la persona para ganar confianza y confianza.

Publicación Especial (SP)

Un tipo de publicación emitida por NIST. Específicamente, la serie SP 800 informa sobre la investigación, las directrices y los esfuerzos de divulgación del Laboratorio de Tecnología de la Información en seguridad informática, y sus actividades de colaboración con la industria, el gobierno y organizaciones académicas.

Sujeto

Una persona, organización, dispositivo, hardware, red, software o servicio.

Suscriptor

Una parte que ha recibido una credencial o autenticador de un CSP.

Clave Simétrica

Una clave criptográfica utilizada para realizar tanto la operación criptográfica como su inversa. Por ejemplo, para cifrar y descifrar o crear un código de autenticación de mensaje y verificar el código.

Token

Ver Autenticador.

Autenticador de Token

Ver Salida del Autenticador.

Secreto del Token

Ver Secreto del Autenticador.

Transacción

Un evento discreto entre un usuario y un sistema que respalda un propósito comercial o programático. Un sistema digital gubernamental puede tener múltiples categorías o tipos de transacciones, que pueden requerir un análisis separado dentro de la evaluación general del riesgo de identidad digital.

Seguridad de la Capa de Transporte (TLS)

Un protocolo de autenticación y seguridad ampliamente implementado en navegadores y servidores web. TLS está definido por RFC 5246. TLS es similar al antiguo protocolo SSL, y TLS 1.0 es efectivamente la versión 3.1 de SSL. La NIST SP 800-52, Directrices para la Selección y Uso de Implementaciones de Seguridad de la Capa de Transporte (TLS) [SP 800-52], especifica cómo se debe usar TLS en aplicaciones gubernamentales.

Ancla de Confianza

Una clave pública o simétrica que es confiable porque está incorporada directamente en hardware o software, o es provisionada de manera segura a través de medios fuera de banda, en lugar de ser avalada por otra entidad confiable (por ejemplo, en un certificado de clave pública). Un ancla de confianza puede tener restricciones de nombre o políticas que limiten su alcance.

Usabilidad

Según ISO/IEC 9241-11: Grado en el que un producto puede ser utilizado por usuarios específicos para alcanzar objetivos específicos con eficacia, eficiencia y satisfacción en un contexto de uso específico.

Verificador

Una entidad que verifica la identidad del reclamante comprobando la posesión y el control del reclamante sobre uno o dos autenticadores utilizando un protocolo de autenticación. Para hacer esto, el verificador también puede necesitar validar credenciales que vinculen el(los) autenticador(es) al identificador del suscriptor y verificar su estado.

Suplantación del Verificador

Un escenario en el que el atacante se hace pasar por el verificador en un protocolo de autenticación, generalmente para capturar información que se pueda utilizar para hacerse pasar por un suscriptor ante el verificador real. En ediciones anteriores de SP 800-63, los protocolos de autenticación que son resistentes a la suplantación del verificador se han descrito como "fuertemente resistentes a MitM".

Prueba de Identidad Virtual en Persona

Un proceso remoto de prueba de identidad que emplea medidas físicas, técnicas y procedimentales que proporcionan suficiente confianza de que la sesión remota puede considerarse equivalente a un proceso de prueba de identidad física y en persona.

Credenciales Débilmente Vinculadas

Credenciales que están vinculadas a un suscriptor de una manera que puede ser modificada sin invalidar la credencial.

Ceroización

Sobrescribir una ubicación de memoria con datos que consisten completamente en bits con el valor cero para que los datos se destruyan y no sean recuperables. Esto a menudo se contrasta con los métodos de eliminación que simplemente destruyen la referencia a los datos dentro de un sistema de archivos en lugar de los datos en sí.

Protocolo de Contraseña de Conocimiento Cero

Un protocolo de autenticación basado en contraseña que permite a un reclamante autenticarse ante un verificador sin revelar la contraseña al verificador. Ejemplos de tales protocolos son EKE, SPEKE y SRP.

A.2 Abreviaturas

Las abreviaturas seleccionadas en estas directrices se definen a continuación.

Abbreviation	Term
ABAC	Attribute Based Access Control
AAL	Authenticator Assurance Level
AS	Authentication Server
CAPTCHA	Completely Automated Public Turing test to tell Computer and Humans Apart
CSP	Credential Service Provider
CSRF	Cross-site Request Forgery
XSS	Cross-site Scripting
DNS	Domain Name System
EO	Executive Order
FACT Act	Fair and Accurate Credit Transaction Act of 2003
FAL	Federation Assurance Level
FEDRAMP	Federal Risk and Authorization Management Program
FMR	False Match Rate
FNMR	False Non-Match Rate
FIPS	Federal Information Processing Standard
FISMA	Federal Information Security Modernization Act
IAL	Identity Assurance Level
IM	Identity Manager
IdP	Identity Provider
IoT	Internet of Things
ISO/IEC	International Organization for Standardization/International Electrotechnical Commission
JOSE	JSON Object Signing and Encryption
JSON	JavaScript Object Notation
JWT	JSON Web Token
KBA	Knowledge-Based Authentication
KBV	Knowledge-Based Verification
KDC	Key Distribution Center
LOA	Level of Assurance
MAC	Message Authentication Code
MitM	Man-in-the-Middle
MitMA	Man-in-the-Middle Attack
MFA	Multi-Factor Authentication
N/A	Not Applicable
NARA	National Archives and Records Administration
OMB	Office of Management and Budget
OTP	One-Time Password
PAD	Presentation Attack Detection
PHI	Personal Health Information
PIA	Privacy Impact Assessment
PII	Personally Identifiable Information
PIN	Personal Identification Number
PKI	Public Key Infrastructure
PL	Public Law
PSTN	Public Switched Telephone Network
RA	Registration Authority
RMF	Risk Management Framework
RP	Relying Party
SA&A	Security Authorization & Accreditation
SAML	Security Assertion Markup Language
SAOP	Senior Agency Official for Privacy
SSL	Secure Sockets Layer
SMS	Short Message Service
SP	Special Publication
SORN	System of Records Notice
TEE	Trusted Execution Environment
TGS	Ticket Granting Server
TGT	Ticket Granting Ticket
TLS	Transport Layer Security
TPM	Trusted Platform Module
VOIP	Voice-over-IP