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 (ID 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.

crealm: A KerberosString that represents the realm in which the user account is located. This value is not case-sensitive.

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

options: Specifies the additional options in the S4U request. Currently, only two options are defined.

Value	Meaning
0x40000000	This option causes the KDC to check logon hour restrictions for the user.
0x20000000	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. This is the KERB_S4U_OPTIONS_use_reply_key_usage (0x20000000).<5> 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.

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].