Información sobre el marco de confianza

MArco de confianza REFEDS en SIR2

El marco de confianza en la federación SIR2, se rige por el marco de confianza REFEDS, que está pensado para modelar la confianza que los servicios tienen de los atributos que les envían los proveedores de identidad de las instituciones que lo implementan.

El marco tiene aplicación de momento sólo a ciertos recursos de eduGAIN, como los disponibles a través de MyAccessID, o determinados recursos de los National Institutes of Health de Estados Unidos.

En este marco, juega un papel especial el atributo eduPersonAssurance.

eduPersonAssurance es un atributo multivaluado y sus valores se han de emitir como lista de elementos. En esta página veremos los posibles valores de este atributo con una descripción y una recomendación de cuando usarlos, pero incluimos primero un breve glosario de términos utilizados en el marco de confianza REFEDS que amplían las nociones clásicas de proveedor de identidad y proveedor de servicio.

Glosario de términos

• CSP (Credential Service Provider): Proveedor de Servicios de Credenciales. Es una entidad que emite o gestiona credenciales de identidad digital. Un CSP valida la identidad de los individuos y emite las credenciales para autenticar la identidad de los usuarios en los sistemas digitales.
• IAP (Identity Assurance Profile): Perfil de Garantía de Identidad. Se refiere al conjunto de requisitos y procesos utilizados para establecer el nivel de confianza en la identidad de un usuario. Estos perfiles ayudan a determinar cómo se verifica la identidad del usuario y la fiabilidad de esa verificación.
• LoA (Level of Assurance): Nivel de Garantía. Indica el grado de confianza que se puede tener en la validez de una identidad digital. Los niveles más altos requieren procesos de verificación más rigurosos y ofrecen mayor seguridad.
• OTP (One Time Password): Contraseña de Un Solo Uso. Es una contraseña que es válida solo para una sesión o transacción. Esta contraseña reduce el riesgo de ataques, ya que no puede ser reutilizada.
• TOTP (Time-based One Time Password): Contraseña de Un Solo Uso Basada en Tiempo. Es un tipo de OTP que se genera a partir de un algoritmo que utiliza el tiempo actual como uno de sus factores. Esto significa que la contraseña es válida solo durante un corto periodo de tiempo.
• HOTP (Hash-based One Time Password): Contraseña de Un Solo Uso Basada en Hash. Utiliza un algoritmo de hash para generar una contraseña única a partir de un contador que cambia cada vez que se genera una contraseña nueva.
• MFA (Multi Factor Authentication): Autenticación de Múltiples Factores. Es un método de control de acceso que requiere que el usuario proporcione dos o más factores de verificación antes de conceder el acceso al recurso solicitado. Estos factores pueden incluir algo que el usuario sabe (una contraseña), algo que el usuario tiene (un teléfono móvil), o algo que el usuario es (biometría).

eduPersonAssurance - Identificadores únicos

En est apartado trataremos valores de eduPersonAssurance que se relacionan con atributos que identifican al usuario, como por ejemplo: eduPersonTargetedID, eduPersonPrincipalName, o eduPersonUniqueID, subject-id (nuevo valor a usar para sustituir a eduPeronTargetedID) o pairwise-id (nuevo valor a usar para sustituir a eduPeronTargetedID con valores distintos para cada servicio).

Se hablará de si cumplen ciertas propiedades como la no reasignación, la unicidad o la persistencia.

^[UN0] El identificador SAML 2.0 es persistente (como el eduPersonTargetedID o, en algunos casos, el eduPersonPrincipalName), un subject-id, pairwise-id o un eduPersonUniqueID
^[UN1] El identificador debe representar a una sola persona.
^[UN2] Se debe tener una forma de contactar con el usuario, a quien pertenece este identificador, mientras esté en uso.
^[UN3] El identificador no debe ser reasignable.

eduPersonAssurance - Calidad y actualidad de los atributos

En este apartado se hablará solo de la calidad y de la actualidad de los atributos que envía un CSP. Estos atributos usados en este apartado serán: eduPersonAffiliation, el eduPersonScopedAffiliation y el eduPersonPrimaryAffiliation.

De cara a aseverar la actualidad o novedad de los valores, se hablará sobre el tiempo que tarda la organización en guardar y cambiar este atributo, y el momento donde se ve reflejado ese cambio.

https://refeds.org/assurance/ATP/ePA-1m

Aparición de faculty, student, staff, employee o member en cualquiera de los atributos citados en esta sección, reflejan con precisión la afiliación del usuario en los sistemas de registro asociados durante los últimos 31 días calendario.

https://refeds.org/assurance/ATP/ePA-1d

Aparición de faculty, student, staff, employee o member en cualquiera de los atributos citados en esta sección, reflejan con precisión la afiliación del usuario en los sistemas de registro asociados durante el día laborable anterior.

eduPersonAssurance - Verificación de identidad y emisión, renovación y sustitución de las credenciales

Esta sección será para evaluar el nivel de LoA que tendrá cada usuario (quedan excluidas de esta sección cuentas genéricas, cuentas que usen varios usuarios y cuentas usadas en scripts o procesos de automatización)

En cada nivel, daremos una pequeña descripción de este (con algún ejemplo). Hablaremos del enrolado, del contacto del usuario, de los métodos de autenticación aceptados y de los controles de seguridad para las credenciales (recordando la parte de los requisitos incremantables).

Nivel LOW garantizado por el CSP

https://refeds.org/assurance/IAP/low

Este nivel se aplicará para las cuentas que no supongan un impacto para la organización en el caso de que se produzca una suplantación de identidad o un acceso fraudulento a raíz de un robo de credenciales.

Un claro ejemplo de esto son cuentas de preinscripción o de pre-matrícula cuya identidad se comprobará a posteriori.

• Enrolado: se corresponde a usuarios generados de forma remota y automática (por ejemplo, cuentas temporales). Se suelen usar mecanismos básicos para identificar que el usuario es una persona (foto, video, captcha). Todos los procesos deberán estar documentados.
• Contacto: lo datos que se tendrán de la cuenta, serán como mucho el correo.
• Métodos de autenticación aceptados: a continuación pondremos una lista de los métodos que se aceptan en este nivel:
  • Contraseña establecida por el usuario.
    
  • Contraseña segura sin caducidad, auto-generada y enviada al usuario por correo o sms, por un canal seguro (SSL para HTTP, SPF-DKIM-DMARC para el correo, riego de clonado de SIM bajo para el caso del sms, …).
    
  • Preguntas pre-establecidas durante el registro (sobre datos mínimamente desconocidos).
    
  • Datos razonablemente desconocidos (fecha de caducidad del DNI, número seguridad social…).
    
  • Cualquier método delos niveles superiores
    
• Controles de credenciales:
  
  • Contraseñas:
    
    • Entropía mínima para que no sea predecible. Se suele pedir un conjunto mínimo de caracteres.
      
    • Medidas contras los ataques de fuerza bruta.
      
    • Fechas de caducidad inferiores a 400 días.
      
  • OTPs:
    
    • Protección anti-replay.
      
    • Tiempo de vida breve.
      
  • Cualquier mecanismo de niveles superiores.
    

Como adición a lo anterior, para el caso de renovación/sustitución/altas/bajas de credenciales, antes de facilitársela, se verificará que el usuario que tiene la credencial, es quien dice ser. En caso de que se pierda la trazabilidad del usuario, no se le dará nuevas claves y se procederá a bloquear la cuenta.

Nivel MEDIUM garantizado por el CSP

https://refeds.org/assurance/IAP/medium

Este nivel se aplicará para las cuentas que puedan suponer un cierto impacto para la organización en el caso de que se produzca una suplantación de identidad o un robo de credenciales.

Además, en este nivel, es necesario llevar un registro de logs de todo el proceso de enrolado de la identidad de los procesos de generación, gestión y entrega, para una posible auditoría. Como resumen, es necesario guardar en los registros de acceso la siguiente información:

1. Cuándo se realiza el proceso.
2. Qué proceso de enrolado se ejecuta (ver mas abajo).
3. Nivel de LoA de la verificación del usuario.
4. Para que sujeto se realiza el proceso.
5. Agentes implicados en el proceso.
6. Información que se añada, elimine o cambie y el mecanismo usado.
7. Pruebas y evidencias solicitadas y recabadas durante el proceso.

Todos los procesos que atañan a las credenciales (entrega, renovación, recuperación, enrolado) deberán estar perfectamente documentadas.

Los sistemas donde se alojen los usuarios deberán de estar actualizados al día, en el ámbito de la seguridad.

Los accesos a estos deberán de ser seguros y controlados.

La seguridad física y lógica de la infraestructura deberá de estar controlada.

Se deberán cumplir ENS (Esquema Nacional de Seguridad) y GDPR (General Data Protection Regulation o Reglamento General de Protección de Datos, en español).

El sistema tendrá que tener medidas anti MitM, medidas antiphising y medidas contra ataques de fuerza bruta.

Se deberán usar protocolos asegurados de la delegación de la confianza, como SAML2.

• Enrolado: usuario real con una verificación mas elaborada que el nivel anterior. Hay unas medidas de seguridad mínimas que se tiene que cumplir, dependiendo de la forma en la que el usuario se da de alta en la organización:
  • Registro en persona:
    • Se solicitará un documento oficial (no hace falta foto).
    • Este documento es el emitido por el país o aceptado como identificación dentro de este (pasaporte o tarjetas de identidad de cada país).
    • Se hará una verificación razonable del documento (por ejemplo ver que no es una falsificación, ni tiene alguna pegatina no oficial, ni está caducado).
  • Registro remoto (supervisado, moderado, automatizado):
    • Verificar la humanidad del solicitante. Como mínimo se pedirá un Captcha, el cual, se puede combinar con lo que se pide en el siguiente punto.
    • Pedir una prueba para asegurar de que tienen una identidad real y oficial. Se puede pedir mostrar por pantalla el documento oficial o enviar una copia digitalizada. Se pueden usar procesos manuales (como tener una videoconferencia y comprobarlo) o se puede hacer de forma automática (una foto o un video de la cara junto al documento oficial y un reto en un papel verificado con un algoritmo que compruebe todo esto)^[1].
    • Todos los métodos remotos tienen que pedir una prueba de identidad adicional. Si se usan procesos automáticos, estos deberán de cumplir todos los procesos de validación como si de un humano se tratase. Si esto último no es posible, deberá intervenir un moderador que compruebe:
    • Que el documento que facilita no está caducado ni revocado.
    • Se deberá pedir alguna prueba adicional, para verificar que la persona es quien dice ser, como por ejemplo: un certificado bancario, alguna factura de los servicios básicos (luz, agua, gas o teléfono) o una declaración escrita por una persona de confianza que realice actividades que impliquen reconocer personas (por ejemplo un empleado de otra organización que pueda ver y pedir el documento de la persona en físico).
    ^[1] si el registro es remoto sin supervisar, este punto no afecta para ese caso.
  • Registro delegado:
    
    • a partir de una autenticación delegada con una identidad REFEDS High, o eIDAS Low (o substantial. o high).
• Contacto: además de lo solicitado en el anterior nivel, se pedirá otra cuenta externa verificada (por ejemplo se puede verificar mandando un enlace para pulsar) y/o teléfono verificado (mediante un reto por SMS o llamada)
• Métodos de autenticación aceptados: a continuación pondremos una lista de los métodos que se aceptan en este nivel:
  • Contraseña establecida por el usuario y con una política de cambio mas estricta que el nivel anterior.
  • Contraseña segura con caducidad, generada por el sistema y enviada por mail o sms.
  • Preguntas pre-establecidas pero mas seguras que el nivel anterior. Estás, serán totalmente privadas o secretos únicos compartidos que no se puedan sacar por fuerza bruta ni se pueden compartir. Este mecanismo se usará solo como última baza o emergencia (un ejemplo claro de esto es el PUK de un móvil)
  • OTP por mail o SMS.
  • HOTP o TOTP.
  • Certificado digital con un identificador asociado a una identidad (como el número del DNI) sin protección PIN.
  • Cualquier mecanismo del nivel High.
• Controles de credenciales: para estos controles, se deberá de cumplir todo lo indicado abajo. Además de todo lo puesto en el nivel low, los controles se dividirán en dos secciones, una para la obtención de las credenciales y otra de las políticas a seguir de estas.
• La obtención de credenciales las dividiremos en dos:
  • Contraseñas obtenidas en persona:
    • Mediante verificación de documento oficial.
    • Mediante contraseña pre-compartida.
  • Contraseñas obtenidas online o por correo:
  • La credencial se entrega encriptada o desactivada y el solicitante habrá obtenido una contraseña o PIN por un medio alternativo para descifrarla o activarla.
• Controles de credenciales:
  
  • Aplicar una restricciones de uso para garantizar la seguridad, como por ejemplo:
• Tiempo de espera entre intento fallidos.
• Incluir Captcha en caso de acumular un número de intentos fallidos.
• Limitar la reutilización de credenciales.
• Limitación del uso de las credenciales.

En caso de pérdida de las credenciales, se deberá de suspender la cuenta hasta que el usuario pueda obtener una nueva de la misma forma que obtuvo las anteriores.

Nivel HIGH garantizado por el CSP

https://refeds.org/assurance/IAP/high

Este nivel se aplicará para las cuentas que puedan suponer un alto impacto para la organización en el caso de que se produzca una suplantación de identidad o un robo de credenciales. Suplantar la identidad de esta persona puede tener graves consecuencias para la institución (por ejemplo, un robo de datos con el cual poder pedir un rescate económico).

En en este nivel de LoA se deberá de cumplir TODOS los puntos del nivel Medium y low, además de los descritos abajo (incluido lo mencionado a los logs, ENS, GDPR, actualizaciones, accesos y resto de controles). Además:

• Se tendrá que tener una gestión responsable de las llaves privadas.
• Deberán de tener todas las medidas posibles para la seguridad HTTP y mail.
• Será altamente recomendable las auditorías internas y/o externas para el personal.
• Se tendrá una revisión periódica de todos los procedimientos.
• Enrolado: usuario real con una verificación aun mas elaborada que el nivel anterior. Se deberán cumplir con todos los puntos del enrolado de nivel medium, además de los de abajo indicados:
  • Registro en persona:
    • El documento oficial tendrá que venir acompañado de una foto y medidas de anti-falsificación.
    • Se realizará una verificación más elaborada que el nivel anterior (se comprobarán las marcas de agua, los hologramas, las fechas de expiración, etc).
    • Comprobación de las fotos con la persona que lo solicita.
    • Aplicar medidas para reducir el riego de uso de un documento revocado, robado o perdido.
  • Registro remoto:
    • Si no está supervisada, en alguna parte del proceso se deberá hacer una comprobación a través de video de la identidad de la persona con el documento de identidad.
  • Registro delegado:
    • a partir de una autenticación delegada con una identidad eIDAS substantial o eIDAS high, o REFEDS High.
• Contacto: todos estos puntos se deben cumplir ya que se pueden usar para recibir notificaciones sensibles o credenciales.
  • Respecto a las formas de verificación:
    • Dirección de correo externa: se mandará un email con un enlace OTP para acceder al servicio autenticado.
    • Teléfono: reto SMS o reto por llamada.
    • Dirección postal: lo mismo que el punto del correo pero por correo postal y entregado en mano de persona indicada.
  • Si el registro es remoto (se tiene que verificar una de estas con un tercero):
  • Conocer el dato de forma autoritaria.
  • Usando un identificador de sujeto, como el DNI y algún dato de contacto personal (email, teléfono, dirección). Con esto se puede analizar si están al mismo nombre de la persona que se está poniendo de contacto.
• Métodos de autenticación aceptados:
  • Autenticación multifactor (MFA):
    • contraseña + OTP
    • contraseña + TOTP
    • contraseña + OTP hardware
    • contraseña + FIDO2
  • Autenticación delegada fuerte: Cl@ve LoA substantial.
  • Certificado digital con protección local (PIN, biometría).
  • Passkeys.
  • Par de tokens cumpliendo lo siguiente:
    • Entrega durante el registro.
    • Distintos tipos
    • Cada uno se entregará por un canal distinto.
    • Si uno de estos tokens lo pone el sujeto, tendrán que cumplir adicionalmente lo siguiente:
      • Cumplimiento de requisitos de seguridad de la organización.
      • Pruebas de este durante el registro (reto criptográfico, verificación visual y enrolado en persona).
• Controles de credenciales: para estos controles, se deberá de cumplir todo lo indicado abajo. Además de todo lo puesto en el nivel medium, los controles se dividirán en una sola sección ya que la entrega de credenciales, se deberá realizarse solo al sujeto:
  • En mano con verificación biométrica (DNI).
  • En un punto de entrega en la que no pueda ser interceptada, con la clave desactivada y facilitando el código de desactivación por un canal distinto.
  • Entrega remota en sesión pre-autenticada usando otra credencia equivalente (Cl@ve).

  En caso de pérdida de las credenciales, se deberá de suspender la cuenta hasta que el usuario pueda obtener una nueva de la misma forma que obtuvo las anteriores.

Nivel local-enterprise IAP

https://refeds.org/assurance/IAP/local-enterprise

Este valor lo emitirá un CSP para dar información de que LoA es necesario para acceder a sus sistemas críticos locales (pueden ser cuentas individuales o colectivas).

Un sistema crítico local se considera a:

• gestionan gastos de la organización.
• gestionan datos de recursos humanos (datos personales de los empleados).
• gestionan datos personales y académicos de los estudiantes.
• gestionan aspectos regulatorios o con efecto sobre las obligaciones de cumplimiento legal y normativo de la organización cualquier otro sistema vital para la continuidad de negocio de la organización.

Este claim es muy poco usado y, aquí en España, suele estar ligado a un nivel high de LoA por el ENS (esto no quiere decir que se pueda emparejar a otros niveles como el low).

Documentación adicional

Actualmente se está desarrollando una amplia guía de aplicación del Marco de Confianza en la federación SIR2, pero queremos listar una serie de documentos que pueden utilizarse también como referencia por instituciones implementando el marco de confianza:

• La fuente principal puede encontrarse en la sección sobre assurance de la web de REFEDS.
• El wiki de REFEDS es también una importante fuente de información en la que encontrar ejemplos prácticos y abundante material como una FAQ y la relación con el perfilde autenticación de múltiples factores.
• Como complemento a la documentación sobre el marco de confianza REFEDS, es importante tener en cuenta los perfiles de autenticación de múltiples factores y de un sólo factor.
• Por último, desde MyAccessID se han descrito los requisitos de acceso, donde tiene aplicación el marco de confianza.