[2]Este documento detalla los enlaces de protocolo con características de seguridad para la Especificación de Gestión de Claves XML (XKMS).
Esta sección describe el estado de este documento al momento de su publicación. Otros documentos pueden reemplazarlo. Una lista de las publicaciones actuales del W3C y la última revisión de este informe técnico puede hallarse en el Índice de informes técnicos del W3C en http://www.w3.org/TR/.
Este documento es una Recomendación del W3C. Ha sido revisado por miembros del W3C y otras partes interesadas, y ha sido avalado por el Director. Es un documento estable y puede ser empleado como material de referencia o citado como referencia normativa en otro documento. El papel del W3C en la creación de la Recomendación es atraer la atención hacia la especificación y fomentar su amplia implementación. Esto mejora la funcionalidad y la interoperabilidad de la Web.
Este documento ha sido creado por el Grupo de Trabajo de XKMS (WG). La versión inglesa de esta especificación es la única con valor normativo. Pueden existir traducciones de este documento.
Si tiene algún comentario sobre este documento, envíelo a www-xkms@w3.org, una lista de correo con un archivo público. Se encuentra disponible una fe de erratas para esta edición.
Esta es la Parte 2 de la Recomendación del W3C para la Especificación de Gestión de Claves XML (XKMS Versión 2.0). Este documento cubre distintos enlaces de protocolo con características de seguridad para la Especificación de Gestión de Claves XML. La Parte 1 de esta especificación cubre los protocolos y servicios XKMS. Para conocer antecedentes de este trabajo, por favor consulte el Informe de actividades de XKMS.
Este documento se basa en la Propuesta de Recomendación sobre Enlaces de XKMS Versión 2.0 del 2 de mayo de 2005. Los Comentarios recibidos durante esa revisión llevaron a algunos cambios menores de redacción. En el Informe de implementación se documentan pruebas de interoperabilidad entre al menos dos implementaciones de esta especificación. Los cambios realizados a este documento desde la Propuesta de recomendación se encuentran detallados en el Apéndice C.
Este documento fue creado bajo la Política actual de patentes del 24 de enero de 2002 modificada por el Procedimiento de transiciones de políticas de patentes del W3C. El Grupo de Trabajo mantiene una lista pública de divulgación de patentes relevantes a este documento; esta página también incluye instrucciones respecto de la divulgación de patentes. Toda persona que tenga conocimiento de una patente que, en su opinión, contenga Reclamos Esenciales respecto a esta especificación, debe divulgar la información, conforme a la sección 6 de la Política de Patentes del W3C.
1.1 Convenciones de redacción y conformidad
[8]Esta especificación utiliza esquemas XML [esquema XML] para describir el modelo de contenido.
[9]Las palabras clave "DEBE", "NO DEBE", "OBLIGATORIO", "DEBERÁ", "NO DEBERÁ", "DEBERÍA", "NO DEBERÍA", "RECOMENDADO", "PUEDE" y "OPCIONAL" en esta especificación deben interpretarse según se describe en [RFC2119]:
[10]"sólo DEBEN utilizarse allí donde sean realmente necesarias para la interoperabilidad o para limitar un comportamiento potencialmente dañino (por ejemplo, para limitar retransmisiones)"
[11]Por consiguiente, empleamos estas palabras clave en mayúsculas para especificar sin ambigüedades requerimientos relativos al protocolo y a características de las aplicaciones y comportamientos que afectan la interoperabilidad y la seguridad de las implementaciones. Estas palabras clave (en mayúsculas) no se usan para describir la gramática XML, pues las definiciones del esquema ya describen estos requerimientos inequívocamente y deseamos reservar la relevancia de estos términos para las descripciones de los protocolos y las características en lenguaje natural. Por ejemplo, un atributo XML podría describirse como "opcional". La conformidad con la especificación de espacios de nombres XML [XML-NS] se describe como "OBLIGATORIA".
[14]Este documento emplea los términos definidos en la Sección 1.2 de la Parte 1 de esta especificación, del modo que allí se describe.
[15]El resto de este documento describe la Especificación del Servicio de Información de Claves XML y la Especificación del Servicio de Registro de Claves XML.
- Sección 2: Requerimientos de seguridad
- Se detallan los requerimientos de seguridad del protocolo XKMS.
- Sección 3: Protocolo de seguridad de carga útil
- Se describen las propiedades de seguridad compatibles con las características de seguridad de carga útil de XKMS.
- Sección 4: Enlaces de seguridad
- Se describe el uso de las características de seguridad de carga útil de XKMS, en función de protocolos específicos de seguridad.
- Sección 5: Consideraciones de seguridad
- Se discuten consideraciones de seguridad concernientes a la implementación y utilización de la especificación.
[16]PUEDEN requerirse mejoras de seguridad para controlar los siguientes riesgos:
- Confidencialidad
- Autenticación de la petición
- Autenticación de la respuesta
- Autenticación persistente
- Repetición de la respuesta
- Sustitución de la petición
- Repetición de la petición
- Denegación de servicio
[17]Las mejoras de seguridad requeridas varían de acuerdo a la aplicación. En el caso de un servicio gratuito o no medido, el servicio puede no requerir autenticación de la petición. Un receptor que requiera autenticación de las peticiones debe saber, en esa circunstancia, que la petición corresponde a la respuesta especificada.
[18]La confidencialidad de los mensajes protege a los mensajes del protocolo de su divulgación a terceros. Un servicio XKMS PUEDE estar sujeto a requerimientos de confidencialidad. Las implementaciones DEBERÍAN considerar hasta qué punto el contenido de los mensajes XKMS revela información delicada. PUEDE existir un requerimiento de confidencialidad incluso si un servicio ofrece únicamente información de fuentes públicas, pues el contenido de una petición podría revelar información sobre el cliente.
[19]La protección de la confidencialidad usando seguridad de transporte o de carga útil NO sustituye la encriptación de claves privadas detallada en los servicios de Registro y Recuperación XKRSS. Un servicio que permite el registro de claves generadas por un servidor o la Recuperación de Claves DEBE implementar el uso de Encriptación XML con un procedimiento de cifrado fuerte.
[20]Un servicio XKMS DEBERÍA ofrecer confidencialidad mediante encriptación.
[21]Esta especificación no precisa los medios por los que el cliente determina que la clave de encriptación del servicio es digna de confianza. Algunos mecanismos posibles:
- Una clave raíz incorporada en la aplicación cliente
- Una clave de firma obtenida mediante el uso de algún otro mecanismo de recuperación tal como PKIX [RFC3280] o SPKI [RFC2693].
[22]Un servicio XKMS PUEDE determinar que una clave de encriptación es confiable por referencia a otro servicio XKMS, a condición de que la cadena de referencias finalmente se funde en un mecanismo que establezca una relación de confianza directa entre el cliente y el servicio.
[23]PUEDE requerirse la autenticación de los mensajes de petición. Un servicio XKMS PUEDE exigir la autenticación de las peticiones en aquellas implementaciones donde el servicio XKMS esté restringido a un público específico, por ejemplo en el caso de servicios pagos. Un servicio XKMS PUEDE exigir la autenticación de las peticiones cuando se ofrezcan diferentes niveles de servicio de acuerdo a la identidad del emisor de la petición.
[24]Además, PUEDEN exigirse varias formas de autenticación en el protocolo de registro XKRSS para confirmar la identidad de la parte que inicia la petición y que ésta posee el componente privado del par o los pares de claves que están siendo registrados.
[25]Un servicio XKMS DEBERÍA permitir la autenticación de las peticiones.
[26]PUEDE requerirse la autenticación de los mensajes de respuesta. La autenticación de mensajes de respuesta es obligatoria en cualquier implementación de un servicio de validación (Validate). Para los servicios de localización (Locate) que sólo provea datos que se autentican a sí mismos, por ejemplo los certificados X.509 o PGP, la autenticación de los mensajes de respuesta no es obligatoria.
[27]Nótese que la autenticación de mensajes de respuesta se considera por separado de la protección contra repetición de respuesta.
[28]Un servicio XKMS DEBERÍA admitir la autenticación de las peticiones.
[29]En algunas circunstancias puede ser necesaria una autenticación persistente de las peticiones, de las respuestas, o de ambas. Por ejemplo, un mensaje enviado por A y autenticado por B puede ser reenviado y autenticado por C. Además, algunas aplicaciones pueden requerir medidas adicionales para asegurar que los mensajes cumplen con ciertas normas legales y así evitar su rechazo.
[30]Un servicio XKMS PUEDE ofrecer autenticación persistente mediante la inclusión de una firma digital en el mensaje.
2.5 Correlación de mensajes (repetición de la respuesta y sustitución de la petición)
[31]Un servicio XKMS DEBE ofrecer un medio para asegurar la correcta correlación de los mensajes. Es decir, el emisor de la petición debe tener la seguridad de que la respuesta que recibe corresponde a la petición que envió al servicio y no a una modificación de esa petición (ataque de sustitución de petición) o a una petición anterior (ataque de repetición de respuesta).
[32]Para prevenir los ataques de repetición de respuesta y de sustitución de mensaje de petición, el emisor de la petición DEBERÍA asegurarse de que la respuesta corresponde a la petición. Para permitir esta verificación de correspondencia, es necesaria la autenticación de la respuesta. En el enlace TLS la correspondencia entre la petición y la respuesta la brinda la capa de transporte. Para los mecanismos de seguridad de capa de mensaje, por ejemplo seguridad de carga útil, el mecanismo requerido depende de si la petición está autenticada o no, según se detalla a continuación:
- Petición autenticada
- Si la petición y la respuesta están autenticadas, la correspondencia entre ambas puede determinarse verificando el valor de RequestId en la respuesta.
- Petición autenticada por resumen
- Si la petición original ha sido autenticada mediante una firma XML con un resumen de mensaje como algoritmo firmante, el servicio aún puede asegurar una fuerte correspondencia entre la respuesta y la petición original mediante el elemento <RequestSignatureValue>.
[33]Un servicio XKMS puede requerir protección contra ataques de repetición de petición. Cuando no se emplea ninguna contabilidad u otro medio de auditoría para llevar un registro de las peticiones hechas, la protección contra ataques de repetición de petición puede no ser necesaria.
[34]Un servicio XKMS PUEDE brindar protección contra ataques de repetición de petición.
[35]Un servicio XKMS puede requerir protección contra ataques de denegación de servicio mediante medidas de protocolo. Estas medidas pueden no ser necesarias cuando el servicio XKMS esté protegido contra denegaciones de servicio mediante otros medios, por ejemplo si el servicio funciona en una red aislada y estrictamente controlada y el servicio no se ofrece fuera de la red.
[36]Los ataques de denegación de servicio provenientes de una única fuente identificada, o de un conjunto de tales fuentes, se pueden neutralizar aplicando controles de velocidad. Cuando el origen del ataque de denegación de servicio esté disfrazado, pueden usarse técnicas de autenticación ligeras, como el protocolo de dos fases que se describe abajo, para detectar peticiones provenientes de direcciones falsas.
[37]Un servicio XKMS DEBERÍA brindar protección contra ataques de denegación de servicio.
[38]La siguiente tabla resume los posibles requerimientos de seguridad a los que una implementación de servicios XKMS puede estar sometida:
| Cuestión de seguridad |
Requerimiento |
Comentarios |
| Confidencialidad |
Algunos |
La información provista por un servicio XKMS puede ser confidencial; el hecho de que una parte haya pedido cierta información a un servicio XKMS puede permitir deducir información confidencial. Sin embargo, muchas aplicaciones XKMS no requieren confidencialidad. |
| Autenticación de petición |
Algunos |
Un servicio solamente necesita autenticar una petición de información si ésta última es confidencial o si el uso del servicio implica algún tipo de pago. |
| Autenticación de respuesta |
La mayoría |
Un servicio XKMS que sólo ofrezca un servicio de ubicación para información de clave que se autentica a sí misma, por ejemplo certificados digitales, no requiere autenticación. |
| Autenticación persistente |
Algunos |
Aunque algunas aplicaciones XKMS tienen un requerimiento específico de no rechazo, la capacidad de rechazar peticiones y respuestas es aceptable en muchas aplicaciones. |
| Correspondencia de mensajes |
Todos |
El mecanismo de correspondencia de RequestId solamente puede usarse si el mecanismo de autenticación de petición es confiable. De lo contrario, debería emplearse el mecanismo de correspondencia por resumen. |
| Repetición de petición |
Algunos |
Los ataques de repetición de petición no constituyen una preocupación, excepto si el servicio cobra por petición o si se usan como un tipo de ataque de denegación de servicio. |
| Denegación de servicio |
La mayoría |
Cualquier servicio disponible en una red pública es susceptible de recibir ataques de denegación de servicio. El riesgo de estos ataques suele considerarse reducido en redes cerradas, por ejemplo redes internas de empresas. |
[39]Donde los requerimientos de seguridad del protocolo XKRSS difieren de aquellos de XKISS, se los trata directamente mediante el protocolo XKRSS en lugar de depender del enlace de seguridad de mensajes.
[40]Por ejemplo, las funciones de registro de XKRSS están diseñadas para permitir su uso en modos en los cuales una petición de registro de un cliente es aceptada por una autoridad local de registro y luego reenviada a una autoridad de registro central. En estos modos, es fundamental que la posesión de la clave privada que se registra puedan verificarla tanto la autoridad local de registro como la autoridad central de registro, incluso aunque es probable que la autenticación de la petición enviada a la autoridad de registro central la provea la autoridad local en lugar del emisor de la petición original. La distribución de claves privadas obedece a consideraciones similares.
| Cuestión de seguridad |
Requerimiento |
Comentarios |
| Confidencialidad de claves privadas |
Si se usan pares de claves generadas por un servidor |
Si un servicio de registro permite el registro de pares de claves generadas por un servidor o la recuperación de claves, DEBE ofrecerse una encriptación fuerte de la clave privada. |
| Autenticación de petición de registro |
Algunos |
Los servicios de registro XKMS DEBERÍAN ofrecer autenticación de peticiones de registro para el registro inicial de un enlace de clave. Las peticiones de registro secundarias de credenciales ya emitidas (por ejemplo, un enlace de clave firmada o un certificado digital) PUEDEN permitirse sin autenticación. |
| Prueba de posesión durante el registro |
Algunos |
Los servicios de registro XKMS DEBERÍAN permitir la verificación de la prueba de posesión durante el registro inicial de claves generadas por el cliente. |
| Autenticación por código de revocación |
Algunos |
El código de revocación XKMS se autentica a sí mismo. |
[41]Esta sección describe un mecanismo para la comunicación de mensajes XKMS, según se definen en la Parte 1 de esta especificación, empleando el protocolo de mensajes SOAP. Para una mejor interoperabilidad, los implementadores de XKMS deberían ofrecer compatibilidad con el protocolo de mensajes SOAP. Al hacerlo, DEBEN utilizar el enlace que se describe aquí. Se especifican los enlaces tanto para SOAP 1.2 [SOAP1.2-1][SOAP1.2-2] como para SOAP 1.1 [SOAP].
[42]Las implementaciones de XKMS 2.0 DEBEN permitir el uso de SOAP 1.2. Para la compatibilidad a corto plazo con las herramientas y la infraestructura existentes, PUEDE usarse SOAP 1.1.
[43]Los implementadores de XKMS deberán utilizar con los mensajes XKMS que se definen en la Parte 1 el estilo SOAP de documento para la mensajería de petición-respuesta, siendo dichos mensajes transportados como contenido literal del elemento Body. Esto equivale a asociar el contenido de Body a un atributo SOAP 1.2 env:encodingStyle con el valor http://www.w3.org/2003/05/soap-envelope/encoding/none.
[44]El enlace XKMS deberá usar el patrón de intercambio de mensajes petición-respuesta de SOAP definido en [SOAP1.2-2] y el procesamiento de los mensajes deberá ser conforme a ese modelo. Para asegurar la interoperabilidad, los mensajes SOAP 1.2 que transporten contenido XKMS deberán emplear la codificación de caracteres UTF-8.
[45]Los mensajes SOAP 1.2 que transporten contenido XKMS deberán cumplir con la siguiente estructura:
[46]Mensaje de petición XKMS
<?xml version='1.0' encoding="utf-8"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Body>
Elemento de mensaje de petición XKMS
</env:Body>
</env:Envelope>
[47]Mensaje de respuesta XKMS
<?xml version='1.0' encoding="utf-8"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Body>
Elemento de mensaje de respuesta XKMS
</env:Body>
</env:Envelope>
[48]El enlace de mensaje XKMS SOAP no requiere el uso de encabezados SOAP. Los mensajes SOAP que transporten contenido XKMS pueden usar encabezados para ofrecer servicios adicionales tales como seguridad de comunicaciones o enrutado. Esta especificación no cubre el uso de esos encabezados. Pero de ser usados, no deben alterar el estilo de codificación de mensajes o el modelo de procesamiento SOAP que se describe aquí.
[49]Aquí se muestra un ejemplo de mensajes LocateRequest y LocateResponse transportados mediante mensajes SOAP 1.2:
[50]Mensaje LocateRequest
<?xml version="1.0" encoding="utf-8"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Body>
<LocateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Id="I8fc9f97052a34073312b22a69b3843b6"
Service="http://www.example.org/XKMS"
xmlns="http://www.w3.org/2002/03/xkms#">
<RespondWith>http://www.w3.org/2002/03/xkms#KeyName</RespondWith>
<RespondWith>http://www.w3.org/2002/03/xkms#KeyValue</RespondWith>
<RespondWith>http://www.w3.org/2002/03/xkms#X509Cert</RespondWith>
<RespondWith>http://www.w3.org/2002/03/xkms#X509Chain</RespondWith>
<RespondWith>http://www.w3.org/2002/03/xkms#PGPWeb</RespondWith>
<RespondWith>http://www.w3.org/2002/03/xkms#PGP</RespondWith>
<QueryKeyBinding>
<KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>
<UseKeyWith Application="urn:ietf:rfc:2440"
Identifier="bob@example.com" />
<UseKeyWith Application="urn:ietf:rfc:2633"
Identifier="bob@example.com" />
</QueryKeyBinding>
</LocateRequest>
</env:Body>
</env:Envelope>
[51]Mensaje LocateResponse
<?xml version="1.0" encoding="utf-8"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Body>
<LocateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Id="I8ce3809ab23500015cc27704b7eb0912"
Service="http://www.example.org/XKMS"
ResultMajor="http://www.w3.org/2002/03/xkms#Success"
RequestId="I8fc9f97052a34073312b22a69b3843b6"
xmlns="http://www.w3.org/2002/03/xkms#">
<UnverifiedKeyBinding Id="I809ca03cf85b3cb466859694dbd0627d">
<ds:KeyInfo>
<ds:KeyValue>
<ds:RSAKeyValue>
<ds:Modulus>
3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV7twNf2T
UXCxYuztUUClMIy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreyn
WegpFbITXc8V6Y02QfR5O7Pn1/10ElslaF/TF8MQGqYE8=
</ds:Modulus>
<ds:Exponent>AQAB</ds:Exponent>
</ds:RSAKeyValue>
</ds:KeyValue>
<ds:X509Data>
<ds:X509Certificate>
MIICCTCCAXagAwIBAgIQe0Sk4xr1VolGFFNMkCx07TAJBgUrDgMCHQUAMBIxEDA
OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj
AkMSIwIAYDVQQDExlCb2IgQmFrZXIgTz1Cb2IgQ29ycCBDPVVTMIGfMA0GCSqGS
Ib3DQEBAQUAA4GNADCBiQKBgQDcUW1ZSy8RqNC3ZJ5IX5G8DFZ08+HkZKVCenxI
O++q8LATo9dxFasgaZXu3A1/ZNRcLFi7O1RQKUwjLXgHRD6TV6Pad6SZgvv4hzc
MMZUVVpg+jFpFjRjaVXy06t7KdZ6CkVshNdzxXpjTZB9Hk7s+fX/XQSWyVoX9MX
wxAapgTwIDAQABo1YwVDANBgNVHQoEBjAEAwIGQDBDBgNVHQEEPDA6gBABpU6Rp
UssqgWYs3fukLy6oRQwEjEQMA4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUq
D4e60DAJBgUrDgMCHQUAA4GBAF4jP1gGDbaq3rg/Vo3JY7EDNTp0HmwLiPMLmdn
B3WTIGFcjS/jZFzRCbvKPeiPTZ6kRkGgydFOuCo5HMAxIks/LtnKFd/0qYT+AOD
q/rCrwSx+F+Ro2rf9tPpja9o7gANqxs6Pm7f1QSPZO57bT/6afiVm7NdaCfjgMp
hb+XNyn
</ds:X509Certificate>
<ds:X509Certificate>
MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAMBIxEDA
OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWj
ASMRAwDgYDVQQDEwdUZXN0IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg
QCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEkeXB8oMxwbhdcizWH92zrtm1V
fVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVRNK5XmKXA5sE
C51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBg
NVHQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQM
A4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GB
ABDYD4Fwx2dscu+BgYcZ+GoQQtCJkwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsi
QgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/MefuTtpOpCN40wy3YwwngD
tHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
<KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
<KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>
<KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage>
<UseKeyWith Application="urn:ietf:rfc:2633"
Identifier="bob@example.com" />
</UnverifiedKeyBinding>
</LocateResult>
</env:Body>
</env:Envelope>
[52]La estructura de los mensajes SOAP 1.2 que transporten otros tipos de mensajes XKMS debería ser evidente a la luz de este ejemplo.
[53]Los implementadores que utilicen mensajería SOAP 1.1 deberán recurrir a una mensajería de tipo petición-respuesta y transportar los mensajes XKMS como contenido literal dentro del elemento SOAP Body. No deberá utilizarse el modelo de codificación descrito en la sección 5 de la especificación de SOAP 1.1. Para asegurar la interoperabilidad, los mensajes SOAP 1.1 que transporten contenido XKMS deberán emplear la codificación de caracteres UTF-8.
[54]La estructura de los mensajes XKMS SOAP 1.1 deberá ser conforme al siguiente modelo:
[55]Mensaje de petición XKMS
<?xml version='1.0' encoding="utf-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Body>
Elemento de mensaje de petición XKMS
</env:Body>
</env:Envelope>
[56]Mensaje de respuesta XKMS
<?xml version='1.0' encoding="utf-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Body>
Elemento de mensaje de respuesta XKMS
</env:Body>
</env:Envelope>
[57]Como con el enlace SOAP 1.2, el enlace SOAP 1.1 no requiere el uso de encabezados SOAP. Los mensajes SOAP que transporten contenido XKMS pueden usar encabezados para ofrecer servicios adicionales tales como seguridad de la comunicación o enrutamiento, mientras que no afecten al estilo de codificación o al modelo de procesamiento SOAP que se describe aquí.
[58]Los mensajes SOAP 1.1 con contenido XKMS son idénticos a los que utilizan SOAP 1.2, excepto por el espacio de nombres de los elementos Envelope y Body. Por lo tanto, los ejemplos que aparecen en la sección 3.1.1 son correctos luego de reemplazar el espacio de nombres de SOAP 1.2 con el de SOAP 1.1 (http://schemas.xmlsoap.org/soap/envelope/).
[59]Al utilizar el enlace XKMS SOAP, los mensajes XKMS se construyen según se define en la Parte 1 de esta especificación, incluyendo todas las declaraciones de espacio de nombres necesarias. El elemento de nivel superior del mensaje se inserta entonces como sub-elemento del elemento SOAP Body. No es obligatorio subir las declaraciones de espacio de nombres de XKMS al nivel del elemento padre SOAP Body (o a su padre, Envelope), pero está permitido a discreción del implementador. Subir las declaraciones generalmente no es deseable si el mensaje XKMS contiene una firma digital, pues tal promoción puede afectar la verificación posterior.
[60]Los mensajes XKMS que se incorporarán en documentos SOAP DEBERÍAN ser firmados mediante el algoritmo de canonización XML exclusiva [XML-EXC-C14N].
[61]El uso del enlace XKMS SOAP no afecta el procesamiento de los elementos <KeyBindingAuthentication> y <ProofOfPossession> basados en firmas XML. Estos se calculan tal como se describe en las secciones 7.1.4 y 7.1.6 de XKMS, respectivamente, y el procesamiento de validación de firma descrito en la sección 3.1.2 de XKMS, elemento <ds:Signature>. Es decir, los nodos y espacios de nombres definidos por SOAP no intervienen en el cálculo de la firma.
[62]Los servicios XKMS deberán usar errores SOAP para comunicar errores que impidan el procesamiento de un mensaje de petición XKMS recibido. Un cliente XKMS nunca debería enviar un mensaje de error SOAP a un servicio XKMS.
[63]Los siguientes mensajes de error SOAP están definidos para su uso con el enlace XKMS SOAP 1.2. Conforme a la especificación SOAP 1.2, estos mensajes de error deberán contener los elementos de información Code y Reason obligatorios. La inclusión de otros elementos queda a discreción del implementador.
[64]En respuesta a un mensaje de petición XKMS, el receptor deberá responder con uno de los siguientes errores SOAP si no puede procesar el mensaje. Si puede procesar el mensaje, entonces la respuesta debería ser conforme a un mensaje de respuesta XKMS válido, tal como se describe en la Parte 1.
- Deberá devolverse un error con Value "env:VersionMismatch" en Code cuando el servicio XKMS encuentre un elemento de información inválido en lugar del elemento de información Envelope esperado, o si el espacio de nombres, el nombre local o ambos no coinciden con elemento de información Envelope requerido. El elemento Reason deberá ser "Unsupported SOAP version".
- Se devolverá un error con Value "env:MustUnderstand" en Code si un sub-elemento de información inmediato del elemento de información SOAP Header no fue comprendido o no fue obedecido por el nodo que ocasionó la falla, cuando el Header contenía un atributo de información mustUnderstand con un valor "true". El valor para Reason deberá ser "Unable to process [nombre del elemento del encabezado]" donde la expresión entre corchetes será reemplazada por el elemento de información del encabezado que produjo el error inicial.
- Se generará un error con Value "env:Receiver" en Code cuando el receptor no pueda manejar el mensaje debido a alguna condición temporaria, por ejemplo, por falta de memoria. El valor para Reason deberá ser "Service temporarily unable".
- Se generará un error con Value "env:Sender" en Code y Value "xkms:MessageNotSupported" en Subcode cuando el receptor no admita el tipo de mensaje de petición. El valor para Reason deberá ser "[tipo de mensaje XKMS] not supported", donde la expresión entre corchetes será reemplazada por el nombre del elemento de información correspondiente al mensaje de petición XKMS recibido.
- Se generará un error con Value "env:Sender" en Code y Value "xkms:BadMessage" en Subcode cuando el receptor no pueda interpretar el mensaje XKMS recibido. El valor para Reason deberá ser "[tipo de mensaje XKMS] invalid", donde la expresión entre corchetes será reemplazada por el nombre del elemento de información correspondiente al mensaje de petición XKMS recibido.
[65]A continuación se muestra un ejemplo del mensaje de error SOAP 1.2 que se devolvería cuando el servicio no admite el mensaje de petición XKMS recibido:
<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Body>
<env:Fault>
<env:Code>
<env:Value>env:Sender</env:Value>
<env:Subcode>
<env:Value>xkms:MessageNotSupported</env:Value>
</env:Subcode>
</env:Code>
<env:Reason>LocateRequest message not supported</env:Reason>
</env:Fault>
</env:Body>
</env:Envelope>
[66]Los siguientes mensajes de error SOAP están definidos para su uso con el enlace XKMS SOAP 1.1. En concordancia con la especificación SOAP 1.1, estos mensajes de error deberán contener los elementos faultcode y faultstring. La inclusión de otros elementos queda a discreción del implementador.
[67]En respuesta a un mensaje de petición XKMS, el receptor deberá responder con uno de los siguientes errores SOAP si no puede procesar el mensaje. Si puede procesar el mensaje, entonces la respuesta debería ser conforme a un mensaje de respuesta XKMS válido, tal como se describe en [XKMS1].
- Se deberá devolver un error con un valor "env:VersionMismatch" para el elemento faultcode cuando el servicio XKMS no encuentre el elemento Envelope esperado, o cuando el espacio de nombres, el nombre local o ambos no coincidan con el elemento Envelope requerido. El elemento faultstring deberá contener el valor "Unsupported SOAP version".
- Se devolverá un error con un valor de "env:MustUnderstand" para el elemento faultcode si un sub-elemento inmediato del elemento SOAP Header no fue comprendido o no fue obedecido por el nodo que ocasionó la falla, cuando el encabezado contenía un atributo mustUnderstand con un valor de "1". El valor para faultstring deberá ser "Unable to process [nombre del elemento del encabezado]", donde la expresión entre corchetes será reemplazada por el primer elemento de información del encabezado que produjo el error.
- Se generará un error con un valor de "env:Server" para faultcode cuando el receptor no pueda manejar el mensaje debido a alguna condición temporaria, por ejemplo por falta de memoria. El elemento faultstring deberá ser "Service temporarily unable".
- Se deberá devolver un error con un valor de "env:Cliente" para faultcode cuando el receptor no admita el tipo de mensaje de petición. El elemento faultstring deberá contener el valor "[tipo de mensaje XKMS] not supported", donde la expresión entre corchetes será reemplazada por el nombre del elemento de información correspondiente al mensaje de petición XKMS recibido.
- Deberá devolverse un error con un valor de "env:Client" para faultcode cuando el receptor no pueda comprender el mensaje XKMS recibido. El elemento faultstring deberá contener el valor "[tipo de mensaje XKMS] invalid", donde la expresión entre corchetes será reemplazada por el nombre del elemento de información correspondiente al mensaje de petición XKMS recibido.
[68]A continuación se muestra un ejemplo del mensaje de error SOAP 1.1 que se devolvería cuando el servicio no admite el mensaje de petición XKMS recibido:
<?xml version="1.0" ?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Body>
<env:Fault>
<env:faultcode>env:Client</env:faultcode>
<env:faultstring>LocateRequest message not supported</env:faultstring>
</env:Fault>
</env:Body>
</env:Envelope>
[69]En una implementación del enlace de XKMS a SOAP 1.2, los mensajes SOAP deberían enviarse utilizando el método HTTP POST, conforme con las recomendaciones de la sección 6.4.2 en [SOAP1.2-2]. El procesamiento será conforme a la sección 7, SOAP HTTP Binding, de esa especificación.
[70]En una implementación del enlace de XKMS a SOAP 1.1, los mensajes SOAP deberían enviarse utilizando el método HTTP POST, conforme con las recomendaciones de la sección 6.1 en [SOAP].
[71]Esta especificación describe dos enlaces de seguridad principales, cada uno de los cuales especifica dos o más perfiles de implementación específicos.
| Característica |
Seguridad de carga útil |
Seguridad de capa de transacción |
| Dependencias |
Autenticación definida por la especificación XKMS, el cliente no necesita implementar un sistema completo |
Mecanismo de autenticación definido por TLS que los clientes deben implementar |
| Uso de firma XML |
Utiliza una firma XML en modo envuelto, lo que requiere un procesamiento ligeramente más complejo |
No requerido |
| Compatibilidad con enrutamiento |
La especificación sólo describe la autenticación bilateral; no se brinda compatibilidad con enrutamiento de mensajes con saltos múltiples y transacciones entre varias partes |
Ninguno |
| Compatibilidad con confidencialidad |
Ninguno, aunque las aplicaciones pueden emplear TLS para establecer un canal seguro |
Admitido |
| No rechazo |
Admitido |
Requiere seguridad de carga útil adicional |
| Autenticación de parte no especificada |
Admitido |
Requiere seguridad de carga útil adicional |
| Autenticación de cliente |
Admitido |
Admitido, mediante un certificado de autenticación de cliente o mediante el uso de seguridad de carga útil |
[71a]
- Modos de autenticación de cliente:
- No se utiliza ningún mecanismo para autenticar al cliente
- El cliente es autenticado utilizando seguridad de carga útil
[71b]En la siguiente tabla, Request/Signature significa que un elemento de petición XKMS incluye un elemento <dsig:Signature> en modo envuelto. Esta firma se calcula utilizando un método de firma digital. Request/MAC tiene el mismo significado, excepto que la firma se calcula utilizando un código de autenticación de mensaje (MAC).
| Consideraciones de seguridad |
Modo de autenticación de cliente |
Soporte |
Comentario |
| Mecanismo de autenticación de cliente |
No se utiliza mecanismo de autenticación. |
Ninguno |
|
| Autenticación mediante seguridad de carga útil |
Carga útil |
Request/Signature |
| Mecanismo de autenticación de servicio |
No se aplica |
Carga útil |
Response/Signature |
| Correspondencia petición/respuesta |
Autenticación mediante seguridad de carga útil |
Carga útil |
Message/RequestId |
| Protección contra ataque por repetición |
Cualquiera |
Carga útil |
Message/Nonce en protocolo de dos fases |
| Protección contra denegación de servicio |
Cualquiera |
Carga útil |
Request/RespondWith=Represent |
| No rechazo |
Cualquiera |
Carga útil |
Message/Signature con firma digital |
[72] Se emplean las siguientes características de seguridad de carga útil:
| elemento XKMS.nombre de atributo |
Obligatorio |
| MessageAbstractType.Service |
Obligatorio |
| MessageAbstractType.Signature |
Obligatorio en un perfil donde el cliente es autenticado mediante seguridad de carga útil tanto para los mensajes de petición como los de respuesta. |
| ResultType.RequestId |
Obligatorio |
| PendingRequestType.ResponseId |
Obligatorio |
| MessageAbstractType.Nonce |
Opcional, puede usarse para proteger contra denegación de servicio |
| MessageAbstractType.RespondWith=Represent |
Opcional, puede usarse para proteger contra denegación de servicio |
| Request.Signature con MAC |
Obligatorio en un perfil donde no se utiliza ningún mecanismo para autenticar al cliente, opcional en un perfil donde el cliente es autenticado mediante seguridad de carga útil |
[73]Cuando se recurra a TLS en XKMS, los receptores de peticiones XKMS DEBEN admitir TLS autenticado por el servidor. Nótese que esto significa que un cliente XKMS sólo necesita admitir TLS anónimo, pues exigir otra cosa obligaría a todos los clientes XKMS a ser capaces de almacenar certificados raíz para el uso de TLS.
Todos los clientes y receptores de peticiones XKMS que admitan TLS DEBEN admitir la suite de cifrado TLS_RSA_WITH_3DES-EDE_CBC_SHA.
Otras suites de cifrado PUEDEN admitirse, pero NO SE RECOMIENDA admitir suites de cifrado débiles pensadas para cumplir con las normas de exportación ("calidad de exportación").
[74]El enlace SSL/TLS tiene tres modos de autenticación de cliente:
- Modos de autenticación de cliente SSL/TLS:
- No se utiliza ningún mecanismo para autenticar al cliente
- Se utiliza autenticación del cliente basada en un certificado TLS
- Autenticación del cliente basada en seguridad de carga útil
[74a]
| Consideraciones de seguridad |
Modo de autenticación de cliente |
Soporte |
Comentario |
| Mecanismo de autenticación de cliente |
No se utiliza mecanismo de autenticación
|
Ninguno |
|
| Autenticación del cliente basada en un certificado TLS |
TLS |
Autenticación del cliente basada en un certificado |
| Autenticación mediante seguridad de carga útil |
Carga útil |
Request/Signature |
| Mecanismo de autenticación de servicio |
No se aplica |
TLS |
|
| Correspondencia petición/respuesta |
Cualquiera |
TLS |
Message/RequestId |
| Protección contra ataque por repetición |
Cualquiera |
TLS |
Message/Nonce en protocolo de dos fases |
| Protección contra denegación de servicio |
Cualquiera |
Ninguno |
TLS no ofrece medidas específicas contra los ataques de denegación de servicio |
| No rechazo |
Cualquiera |
Carga útil |
Message/Signature con firma digital [si es necesario] |
[75] Se emplean las siguientes características de seguridad de carga útil:
| elemento XKMS.nombre de atributo |
Obligatorio |
| MessageAbstractType.Service |
Requerido, pero no dependiente |
| MessageAbstractType.Signature |
Opcional, puede ser usado para admitir no rechazo tanto para los mensajes de petición como los de respuesta |
| ResultType.RequestId |
Requerido, pero no dependiente |
| PendingRequestType.ResponseId |
Requerido, pero no dependiente |
| MessageAbstractType.Nonce |
Innecesario |
| MessageAbstractType.RespondWith=Represent |
Innecesario |
[76] [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119, marzo de 1997. http://www.ietf.org/rfc/rfc2119.txt.
[77] [RFC2246] T. Dierks, C. Allen., The TLS Protocol Version, 1.0. IETF RFC 2246 enero de 1999. http://www.ietf.org/rfc/rfc2246.txt
[78] [RFC2693] C. Ellison et. al., Simple Public Key Infrastructure Certificate Theory, IETF RFC 2693, sept. de 1999. http://www.ietf.org/rfc/rfc2693.txt
[79] [RFC3280] R. Housley et. al., Public Key Infrastructure (X.509) (PKIX) Certificate and Certificate Revocation List (CRL) Profile, IETF RFC 3280, abril de 2002 ,http://www.ietf.org/rfc/rfc3280.txt
[80] [SOAP] D. Box, D Ehnebuske, G. Kakivaya, A. Layman, N. Mendelsohn, H. Frystyk Nielsen, S Thatte, D. Winer. Simple Object Access Protocol (SOAP) 1.1, Nota del W3C, 8 de mayo de 2000. http://www.w3.org/TR/2000/NOTE-SOAP-20000508/
[81] [SOAP1.2-1] M. Gudgin, et al. SOAP Version 1.2 Part 1: Messaging Framework, Recomendación del W3C, 24 de junio de 2003. http://www.w3.org/TR/2003/REC-soap12-part1-20030624/
[82] [SOAP1.2-2] M. Gudgin, et al. SOAP Version 1.2 Part 2: Adjuncts, Recomendación del W3C, 24 de junio de 2003. http://www.w3.org/TR/2003/REC-soap12-part2-20030624/
[85] [XML-SIG] D. Eastlake, J. R., D. Solo, M. Bartel, J. Boyer , B. Fox , E. Simon. XML-Signature Syntax and Processing, Recomendación del W3C. http://www.w3.org/TR/xmldsig-core/
[86] [XML-SIG-XSD] Esquema de firma XML disponible en http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd
[86a] [XML-EXC-C14N] J. Boyer, D. E. Eastlake, J. Reagle. Exclusive XML Canonicalization. Recomendación del W3C, 8 de julio de 2002. http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/
[87] [XML-Enc] D. Eastlake, J. Reagle, T. Imamura, B. Dillaway, E. Simon, XML Encryption Syntax and Processing, Recomendación del W3C, 10 de diciembre de 2002. http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/
[88] [XML-NS] T. Bray, D. Hollander, A. Layman. Namespaces in XML. Recomendación del W3C. Enero de 1999. http://www.w3.org/TR/1999/REC-xml-names-19990114
[89] [XML-Schema1] H. S. Thompson, D. Beech, M. Maloney, N. Mendelsohn. XML Schema Part 1: Structures Second Edition, Recomendación del W3C, 28 de octubre de 2004. http://www.w3.org/TR/xmlschema-1/
[90] [XML-Schema2] P. V. Biron, A. Malhotra, XML Schema Part 2: Datatypes Second Edition; Recomendación del W3C, 28 de octubre de 2004. http://www.w3.org/TR/xmlschema-2/
[91]Esta especificación es resultado del trabajo del Grupo de Trabajo de Gestión de Claves XML del W3C. Se agradecen las contribuciones de los siguientes miembros del Grupo de Trabajo a esta especificación, de acuerdo con las políticas de colaboración y la activa nómina del grupo de trabajo.
[92]Los participantes en el Grupo de Trabajo son (al momento de escribir, y por orden alfabético): Guillermo Alvaro Rey (Trinity College Dublin), Stephen Farrell (Trinity College Dublin, vicepresidente), José Kahan (W3C, contacto del grupo), Berin Lautenbach (Apache Software Foundation), Tommy Lindberg (Markup Security), Roland Lockhart (Entrust, Inc.), Vamsi Motukuru (Oracle Corp.), Shivaram Mysore (vicepresidente; editor desde el 13 de abril de 2004), Rich Salz (DataPower Technology, Inc.), Yunhao Zhang (SQLData Systems).
[93]Los participantes anteriores fueron (en orden alfabético): Daniel Ash (Identrus), Blair Dillaway (Microsoft), Donald Eastlake 3rd (Motorola), Yassir Elley (Sun Microsystems), Jeremy Epstein (webMethods), Slava Galperin (Sun Microsystems), Phillip Hallam-Baker (VeriSign Inc, editor hasta el 13 de abril de 2004), Loren Hart (VeriSign Inc.), Mack Hicks (Bank of America), Merlin Hughes (Baltimore), Frederick Hirsch (Nokia Mobile Phones), Mike Just (Treasury Board of Canada Secretariat), Brian LaMacchia (Microsoft), Pradeep Lamsal, Joseph Reagle (W3C, anterior contacto del grupo), Dave Remy (GeoTrust, Inc.), Peter Rostin (RSA Security Inc.), Ed Simon (XMLsec Inc.)
[94]Los autores también agradecen la amplia asistencia brindada en la etapa de diseño de esta especificación por David Solo (CitiGroup) y Barbara Fox (Microsoft), y las contribuciones de (en orden alfabético): Dr. Paul Boisen (NSA), Alex Deacon, Dan Guinan, Marc Hayes, Jeremy Epstein (webMethods), Andrew Layman (Microsoft), Mingliang Pei (VeriSign).
Este apéndice registra las modificaciones (sin incluir cambios de redacción de muy poca importancia) realizadas sobre la Propuesta de recomendación del 2 de mayo de 2005 en respuesta a los comentarios. Cada ítem incluye:
- un número de modificación
- una breve descripción y, en caso de ser apropiado, las medidas que se tomaron
- un enlace al mensaje que llevó a la modificación (si el mensaje es público)
-
Modificación. Era confuso el texto en el p. [60] sobre cómo evitar colisiones de los prefijos de los espacios de nombres al incorporar mensajes XKMS en documentos SOAP. Esto se modificó, de modo que dijera que los mensajes XKMS DEBERÍAN firmarse utilizando exc-c14n, lo cual ya se sugería en los pp. [89] y [90] de la especificación XKMS. (345-ml)
-
Corrección. Los pp. 46, 47, 55, 56 de la Parte 2 indicaban incorrectamente que el elemento SOAP Body reside dentro del elemento SOAP Header. (338-tl-1)
-
Corrección. El p. 47 tenía un punto y coma de más al final. (338-tl-2)
-
Corrección. Se aclaró el p. 43 de modo que dijera que los mensajes XKMS se transportan en los mensajes SOAP 1.2 como contenido literal del elemento Body. Se quitó la justificación de por qué no se seleccionó la codificación, por haberse vuelto irrelevante. (339-ml)
-
Corrección. Se aclaró el p. 53 de modo que dijera que los mensajes XKMS se transportan en los mensajes SOAP 1.1 como contenido literal del elemento Body. (348-ml)
