Kerberos: ¿Cuál es la estructura para la autenticación previa con certificado (RFC 4556)

Question

Kerberos: ¿Cuál es la estructura para la autenticación previa con certificado (RFC 4556)

#1 de ecdsa (1 votos)

5

Me cuesta entender cómo debería ser la estructura de una solicitud de autenticación previa en kerberos. Después de leer el RFC 4556 y los RFC referenciados, todavía estoy confundido debido a todos los diferentes casos.

Mi caso de uso es el siguiente: quiero autenticarme en un dominio de Windows con un certificado que recuperé de la CA que pertenece al dominio. El certificado contiene la URL de crl y su algoritmo de firma es sha256RSA. La clave pública contenida es una clave RSA2048. Según tengo entendido, debo enviar este certificado y firmarlo. También soy consciente de que debo enviar un correo electrónico para evitar los ataques de repetición.

No tengo claro qué se debe firmar, es decir, qué se debe incluir en esta parte de la solicitud.

PA-PK-AS-REQ ::= SEQUENCE {
          signedAuthPack          [0] IMPLICIT OCTET STRING,
                   -- Contains a CMS type ContentInfo encoded
                   -- according to [RFC3852].

RFC 3852 estados:

SignedData ::= SEQUENCE {
        version CMSVersion,
        digestAlgorithms DigestAlgorithmIdentifiers,
        encapContentInfo EncapsulatedContentInfo,
        certificates [0] IMPLICIT CertificateSet OPTIONAL,
        crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
        signerInfos SignerInfos }

Aunque todos estos puntos tienen muchas explicaciones, me temo que soy un tonto porque no lo entiendo. Especialmente lo que pertenece a la versión y encapContentInfo (creo que la firma debe ir en el campo de contenido del EncapsulatedContentInfo, pero no estoy seguro).

Como la especificación es un poco confusa, simplemente no entiendo qué más debe haber en esta solicitud y qué no.

¿Alguien puede arrojar algo de luz sobre esto y aclarar cómo debería ser la estructura de la solicitud completa?

EDIT

Bien, después de algunas investigaciones estoy aún más confundido. RFC 4556 establece que la estructura de PkAuthenticator en el AuthPack debería tener este aspecto:

PKAuthenticator ::= SEQUENCE {
    cusec                   [0] INTEGER -- (0..999999) --,
    ctime                   [1] KerberosTime,
    nonce                   [2] INTEGER (0..4294967295),
    paChecksum              [3] OCTET STRING OPTIONAL,
    ...
}

Detectando el tráfico de autenticación con tarjeta inteligente con wireshark Obtuve esta PKAuthenticator-structure en un entorno de Microsoft:

SEQUENCE(1 elem)
    [0](1 elem)
        SEQUENCE(5 elem)
            [0](1 elem)
                SEQUENCE(2 elem)
                    [0](1 elem)
                        INTEGER2
                    [1](1 elem)
                        SEQUENCE(2 elem)
                            GeneralString
                            GeneralString
            [1](1 elem)
                GeneralString
            [2](1 elem)
                INTEGER 563793
            [3](1 elem)
                GeneralizedTime 2016-12-01 13:53:08 UTC
            [4](1 elem)
                INTEGER 1051204026

¿Es este el comportamiento habitual de Microsoft haciendo lo suyo independientemente de lo que diga la especificación o me falta algo?

authentication kerberos

pregunta Frank 21.11.2016 - 15:07

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication kerberos

Qué seguridad tiene OSX y por qué necesita o no antivirus [duplicado] Extraer código malicioso del archivo PDF

score 1 · Accepted Answer

Me dirijo a la pregunta que agregó con su edición.

Como está documentado por Microsoft , algunas versiones de Windows ( "< 2 > Sección 2.2: La sintaxis del mensaje [RFC4556] no se admite en Windows 2000, Windows XP y Windows Server 2003. ") se basan en un borrador anterior de RFC 4556 que definía la siguiente estructura para PKAuthenticator (draft versión 11 fue la última en utilizar esta sintaxis para PKAuthenticator ):

--
-- PK-AUTHENTICATOR - Different from [RFC4556]
-- Appendix A, PKAuthenticator.
--
PKAuthenticator::= SEQUENCE {
     kdc-name   [0] PRINCIPAL-NAME,
     kdc-realm  [1] REALM,
 -- name and realm of the KDC issuing the ticket
     cusec      [2] INTEGER,
     ctime      [3] KerberosTime,
     nonce      [4] INTEGER
 }

Con el RFC final (borrador versión 22 en realidad) el el identificador para PA-PK-AS-REP también cambió de 15 a 17 para distinguir entre las dos especificaciones de formato (Microsoft también lo menciona: "Un borrador anterior de [RFC4556] admitía un identificador de datos de autenticación previa diferente: PA- PK-AS-REP_OLD 15 ").