PA-DATA

Historically, PA-DATA have been known as "pre-authentication data", meaning that they were used to augment the initial authentication with the KDC. Since that time, they have also been used as a typed hole with which to extend protocol exchanges with the KDC.

PA-DATA ::= SEQUENCE {

-- NOTE: first tag is [1], not [0]

padata-type [1] Int32,

padata-value [2] OCTET STRING -- might be encoded AP-REQ }

padata-type

Indicates the way that the padata-value element is to be interpreted. Negative values of padata-type are reserved for unregistered use; non-negative values are used for a registered interpretation of the element type.

padata-value

Usually contains the DER encoding of another type; the padata-type field identifies which type is encoded here.

padata-type Name Contents of padata-value 1 pa-tgs-req DER encoding of AP-REQ

2 pa-enc-timestamp DER encoding of PA-ENC-TIMESTAMP 3 pa-pw-salt salt (not ASN.1 encoded)

11 pa-etype-info DER encoding of ETYPE-INFO 19 pa-etype-info2 DER encoding of ETYPE-INFO2 This field MAY also contain information needed by certain extensions to the Kerberos protocol. For example, it might be used to verify the identity of a client initially before any response is returned.

The padata field can also contain information needed to help the KDC or the client select the key needed for generating or

decrypting the response. This form of the padata is useful for supporting the use of certain token cards with Kerberos. The details of such extensions are specified in separate documents.

See [Pat92] for additional uses of this field.

5.2.7.1. PA-TGS-REQ

In the case of requests for additional tickets (KRB_TGS_REQ), padata-value will contain an encoded AP-REQ. The checksum in the authenticator (which MUST be collision-proof) is to be computed over the KDC-REQ-BODY encoding.

5.2.7.2. Encrypted Timestamp Pre-authentication

There are authentication types that may be used to authenticate a client by means of an encrypted timestamp.

PA-ENC-TIMESTAMP ::= EncryptedData -- PA-ENC-TS-ENC PA-ENC-TS-ENC ::= SEQUENCE {

patimestamp [0] KerberosTime -- client’s time --, pausec [1] Microseconds OPTIONAL

}

Patimestamp contains the client’s time, and pausec contains the

microseconds, which MAY be omitted if a client will not generate more than one request per second. The ciphertext (padata-value) consists of the PA-ENC-TS-ENC encoding, encrypted using the client’s secret key and a key usage value of 1.

This pre-authentication type was not present in RFC 1510, but many implementations support it.

5.2.7.3. PA-PW-SALT

The padata-value for this pre-authentication type contains the salt for the string-to-key to be used by the client to obtain the key for decrypting the encrypted part of an AS-REP message. Unfortunately, for historical reasons, the character set to be used is unspecified and probably locale-specific.

This pre-authentication type was not present in RFC 1510, but many implementations support it. It is necessary in any case where the salt for the string-to-key algorithm is not the default.

In the trivial example, a zero-length salt string is very commonplace for realms that have converted their principal databases from

Kerberos Version 4.

A KDC SHOULD NOT send PA-PW-SALT when issuing a KRB-ERROR message that requests additional pre-authentication. Implementation note:

Some KDC implementations issue an erroneous PA-PW-SALT when issuing a KRB-ERROR message that requests additional pre-authentication.

Therefore, clients SHOULD ignore a PA-PW-SALT accompanying a

KRB-ERROR message that requests additional pre-authentication. As noted in section 3.1.3, a KDC MUST NOT send PA-PW-SALT when the client’s AS-REQ includes at least one "newer" etype.

5.2.7.4. PA-ETYPE-INFO

The ETYPE-INFO pre-authentication type is sent by the KDC in a

KRB-ERROR indicating a requirement for additional pre-authentication.

It is usually used to notify a client of which key to use for the encryption of an encrypted timestamp for the purposes of sending a PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an AS-REP to provide information to the client about which key salt to use for the string-to-key to be used by the client to obtain the key for decrypting the encrypted part the AS-REP.

ETYPE-INFO-ENTRY ::= SEQUENCE { etype [0] Int32,

salt [1] OCTET STRING OPTIONAL }

ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY

The salt, like that of PA-PW-SALT, is also completely unspecified with respect to character set and is probably locale-specific.

If ETYPE-INFO is sent in an AS-REP, there shall be exactly one ETYPE-INFO-ENTRY, and its etype shall match that of the enc-part in the AS-REP.

This pre-authentication type was not present in RFC 1510, but many implementations that support encrypted timestamps for

authentication need to support ETYPE-INFO as well. As noted in Section 3.1.3, a KDC MUST NOT send PA-ETYPE-INFO when the client’s AS-REQ includes at least one "newer" etype.

5.2.7.5. PA-ETYPE-INFO2

The ETYPE-INFO2 pre-authentication type is sent by the KDC in a

KRB-ERROR indicating a requirement for additional pre-authentication.

It is usually used to notify a client of which key to use for the encryption of an encrypted timestamp for the purposes of sending a PA-ENC-TIMESTAMP pre-authentication value. It MAY also be sent in an AS-REP to provide information to the client about which key salt to use for the string-to-key to be used by the client to obtain the key for decrypting the encrypted part the AS-REP.

ETYPE-INFO2-ENTRY ::= SEQUENCE { etype [0] Int32,

salt [1] KerberosString OPTIONAL, s2kparams [2] OCTET STRING OPTIONAL }

ETYPE-INFO2 ::= SEQUENCE SIZE (1..MAX) OF ETYPE-INFO2-ENTRY The type of the salt is KerberosString, but existing installations might have locale-specific characters stored in salt strings, and implementors MAY choose to handle them.

The interpretation of s2kparams is specified in the cryptosystem description associated with the etype. Each cryptosystem has a

default interpretation of s2kparams that will hold if that element is omitted from the encoding of ETYPE-INFO2-ENTRY.

If ETYPE-INFO2 is sent in an AS-REP, there shall be exactly one ETYPE-INFO2-ENTRY, and its etype shall match that of the enc-part in the AS-REP.

The preferred ordering of the "hint" pre-authentication data that affect client key selection is: ETYPE-INFO2, followed by ETYPE-INFO, followed by PW-SALT. As noted in Section 3.1.3, a KDC MUST NOT send ETYPE-INFO or PW-SALT when the client’s AS-REQ includes at least one "newer" etype.

The ETYPE-INFO2 pre-authentication type was not present in RFC 1510.