Resumen

  • draft-cel-nfsv4-rpc-tls-othername-04, fechado el 5 de septiembre de 2026, propone incluir una identidad de usuario RPC en un otherName de subjectAltName. Es un Internet-Draft individual, no un RFC, ni consenso del IETF, ni prueba de despliegue.
  • Cuando el servidor aplica el mecanismo, reemplaza la identidad de la cabecera AUTH_NONE o AUTH_SYS por la identidad validada del certificado. Si no puede mapearla o autorizarla, responde AUTH_TOOWEAK y no puede volver a la cabecera.
  • Un servidor que no lo implementa, o que lo tiene desactivado, ignora el campo y procesa la credencial RPC ordinaria. El cliente no puede distinguir ambos casos; por eso, emitir el certificado no demuestra que la restricción operó.

Una copia nocturna llega a dos nodos con el mismo certificado. En el primero, aunque la llamada diga UID 0, el proceso queda reducido a la cuenta backup indicada por el certificado. En el segundo, la sesión TLS también es válida, pero el nuevo identificador resulta desconocido: el nodo vuelve a leer el UID de la cabecera.

No hay dos certificados ni una rotura del cifrado. Hay dos superficies de autorización escondidas detrás de una conexión que, vista desde el cliente, parece igual.

La revisión 04 del borrador intenta cerrar una separación deliberada de RFC 9289. RPC sobre TLS aporta confidencialidad, integridad y autenticación entre pares, pero no decide qué usuario RPC representa cada petición. La propuesta permite que el certificado cliente lleve un usuario, que el servidor lo valide al establecer la sesión y que ese resultado sustituya las afirmaciones más débiles de cada llamada.

Hay tres representaciones. RPCAuthSys transporta UID y GID numéricos. GSSExportedName contiene un nombre exportado por un mecanismo GSS, con el caso de Kerberos descrito en RFC 4121. NFSv4Principal usa el formato user@domain de RFC 8881, que el servidor resuelve mediante su mapeo de propietarios.

No son alternativas intercambiables. Los números dependen de directorios de usuarios coherentes; el nombre GSS, de un mecanismo realmente admitido; y el principal NFSv4, de reglas locales de dominio. Si un certificado contiene más de una forma de reducción de identidad, el servidor debe rechazarlo. Dos respuestas firmadas no componen una respuesta más segura.

La regla decisiva es no regresar a la cabecera

El servidor que aplica el borrador valida primero la cadena X.509 conforme a RFC 5280 y a RPC con TLS. Después identifica una única forma, obtiene un usuario local y decide si ese par autenticado puede emplearlo. Puede consultar listas por sujeto de certificado, rangos de UID y grupos, patrones de dominio o políticas de mecanismos GSS.

Si todo encaja, el usuario queda ligado a esa sesión TLS. Para cada llamada AUTH_NONE o AUTH_SYS, se descarta la identidad de la cabecera definida por RFC 5531. RPCSEC_GSS permanece al margen: su contexto de RFC 2203 ya acreditó una identidad y no debe ser sustituido.

El recorrido de error importa aún más. Una identidad mal formada, imposible de resolver o no autorizada provoca AUTH_TOOWEAK en los procedimientos no NULL afectados. El texto prohíbe entonces aceptar la identidad de la cabecera. Ese atajo devolvería exactamente la autoridad que el certificado pretendía retirar.

Pero una norma nueva no puede ordenar a un binario viejo que la entienda. El perfil conserva subjectAltName como extensión no crítica y aloja el significado nuevo en el identificador de tipo de otherName. Una aplicación antigua puede reconocer SAN, desconocer ese tipo y omitirlo. Un servidor moderno con la función desactivada termina en la misma conducta, y el cliente no sabe cuál de los dos ha atendido la sesión.

Es una decisión de interoperabilidad. Marcar SAN como crítico podría llevar a software antiguo a rechazar también otros nombres válidos del certificado. Mantenerlo no crítico permite la convivencia, pero impide convertir el contenido firmado en garantía portátil de ejecución.

La unidad de prueba es el nodo que sirvió la sesión

Un inventario útil no cruza solamente certificado y fecha de caducidad. Debe unir perfil de emisión, ancla de confianza, versión del nodo, estado del mecanismo, alcance de la política, datos de mapeo, modalidad RPC y sesión concreta. El borrador permite aplicar la reducción en todo el servidor, por exportación o en otra unidad local; decir que un producto «la admite» no dice dónde está activa.

En una granja heterogénea, el equilibrador puede enviar una conexión al nodo que sustituye el UID y la siguiente al que lo conserva. Ambos responden. El panel de disponibilidad queda verde. La semántica de acceso, no obstante, ha cambiado entre sesiones.

La revocación solo cubre otro tramo. Como estos certificados pueden conceder acceso bajo una identidad de usuario, importan su vigencia y la actualidad de CRL u OCSP. La revisión recomienda anclas separadas para los certificados de reducción y los que solo autentican al par TLS. Ni una respuesta de revocación reciente demuestra que el OID fue interpretado, ni un OID interpretado demuestra que el mapa local era correcto.

La sección de implementaciones registra como completa una aportación para FreeBSD sobre user@domain. El propio documento aclara que la declaración procede de los contribuidores, no es respaldo del IETF, no fue verificada de forma independiente y no constituye un catálogo; tampoco reporta experiencia de implementación. RFC 7942 explica el valor de documentar código existente, pero una ficha de estado no es un recibo de producción.

La distinción encaja con las capas de realidad de Heng Lu: campo firmado, decisión del servidor y efecto sobre el recurso son evidencias distintas. La primacía del código en ejecución obliga a mirar el binario que atendió. Una especificación inicial mínima puede fijar el suelo común sin fingir que todos los nodos ya lo adoptaron.

La pregunta de auditoría queda así: ¿qué nodo demostró que usó la identidad del certificado en esta sesión y rechazó la alternativa de la cabecera?

Fuentes