2.2.2 PA_S4U_X509_USER

If the service possesses the user certificate, it can obtain a service ticket to itself on that user's behalf using the S4U2self TGS exchange subprotocol extension, with a new padata type PA-S4U-X509-USER (130).<4> This padata type contains a unique identifier that indicates the user's identity. This unique identifier consists of the user's certificate and, optionally, the user's name and realm.

The following code defines the structure of the PA-S4U-X509-USER padata type.

 Message Type      padata-type    Contents of padata-value
  
 AS-REQ            130            X509 certificate encoded per [RFC3280]
  
 TGS-REQ/TGS-REP   130            PA-S4U-X509-USER ASN.1 structure

The corresponding data contains the DER encoded PA-S4U-X509-USER structure.

 PA-S4U-X509-USER::= SEQUENCE {
    user-id             [0] S4UUserID,
    checksum            [1] Checksum
 }
  
 S4UUserID ::= SEQUENCE {
    nonce               [0] UInt32, -- the nonce in KDC-REQ-BODY
    cname               [1] PrincipalName OPTIONAL, -- Certificate mapping hints
    crealm              [2] Realm,
    subject-certificate [3] OCTET STRING OPTIONAL, 
    options             [4] BIT STRING OPTIONAL,
    ...
 }

user-id: Contains the user identifiers. This can be either the user name and realm or the user's certificate.

checksum: This is the Kerberos checksum (as defined in [RFC3961]) computed over the DER encoding of the ASN.1 type S4UUserID contained in the user-id field that immediately precedes this field. The key used is the session key of the TGT used in the TGS request (note that the same key is used in the TGS request and reply when this padata is used in both the request and the reply); the checksum operation is the required checksum for the encryption type of that TGT session key per [RFC3961]; and the key usage is 26. Because there is no required checksum type defined for the encryption type RC4_HMAC_NT (23), if the key's encryption type is RC4_HMAC_NT (23) the checksum type is rsa-md4 (2) as defined in section 6.2.6 of [RFC3961]. If the encryption type is "not-newer" (note that the term "not-newer" is described in section 1 of [RFC4121]), a padata element of type 130 is included in the encrypted-pa-data field of the reply (note that the encrypted-pa-data field is described in appendix A of [RFC6806]). The padata of type 130 in the encrypted-pa-data field contains the checksum value in the S4U request concatenated with the checksum value in the S4U reply. The checksum value of a Kerberos Checksum type here refers to the OCTET STRING of the Checksum field. The client when receiving this padata type in the encrypted-pa-data field MUST verify the checksum values match with the corresponding checksum values in the request and the reply.

nonce: This contains the identically named field in the KDC body of the containing request.

cname: The PrincipalName type discussed in detail in [RFC4120] section 5.2.2. It consists of a name type and name string. The default value for the name type is NT-UNKNOWN as specified in [RFC4120] section 6.2. The name string is a sequence of strings encoded as KerberosString, as specified in [RFC4120] section 5.2.1, that (together with the crealm) represents a user principal. The name string is case sensitive and MUST not be canonicalized by the KDC.

crealm: A KerberosString that represents the realm in which the user account is located. This value is not case-sensitive; however, it will not be canonicalized by the KDC.

subject-certificate: This optional field contains the user's certificate that is encoded as specified in [RFC3280].

options: Specifies additional options in the S4U request.

Value	Meaning
0x80000000	KERB_S4U_OPTIONS_reserved. Reserved.
0x40000000	KERB_S4U_OPTIONS_check_logonhours This option causes the KDC to check logon hour restrictions for the user. Note that logon hour restrictions are calculated based on the time zone of the DC, not of the client.
0x20000000	KERB_S4U_OPTIONS_use_reply_key_usage<5> In a request, asks the KDC to sign the reply with key usage number 27. In a reply, indicates that it was signed with key usage number 27. If this option is set in the request, and if the KDC understands this option, it will sign the reply with key usage number 27 and set the same option in the reply. Otherwise, it will sign the reply with key usage number 26 and not set the option in the reply.
0x10000000	KERB_S4U_OPTIONS_nt_auth_policy_not_required This option causes the KDC to omit NTAuth store certificate chain checks and is designed for scenarios where the client performs its own chain checks. If this setting is used incorrectly, it can pose a security risk due to potentially unchecked certificate chains. This bit can be processed by DCs who understand and ignored by those who don't. A DC processing the bit would reply the same if succeed. The value STATUS_NO_SUCH_USER is returned if a DC ignoring the bit has processed the request.
0x08000000	KERB_S4U_OPTIONS_unconditional_delegation. Unconditional delegation.

The SFU client needs to be able to locate the KDC of the user's realm. If the S4U call is based on the certificate and no user name is supplied, the client uses a PA_S4U_X509_USER padata type and the corresponding data contains the user's X509 certificate encoded as specified in [RFC3280].