Connected: An Internet Encyclopedia
RFC 1510 - 5.4.1. KRB_KDC_REQ definition

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1510
Up: 5. Message Specifications
Up: 5.4. Specifications for the AS and TGS exchanges
Prev: 5.4. Specifications for the AS and TGS exchanges
Next: 5.4.2. KRB_KDC_REP definition

### 5.4.1. KRB_KDC_REQ definition

The KRB_KDC_REQ message has no type of its own. Instead, its type is one of KRB_AS_REQ or KRB_TGS_REQ depending on whether the request is for an initial ticket or an additional ticket. In either case, the message is sent from the client to the Authentication Server to request credentials for a service.

The message fields are:

    AS-REQ ::=         [APPLICATION 10] KDC-REQ
    TGS-REQ ::=        [APPLICATION 12] KDC-REQ

    KDC-REQ ::=        SEQUENCE {
               pvno[1]               INTEGER,
               msg-type[2]           INTEGER,
               padata[3]             SEQUENCE OF PA-DATA OPTIONAL,
               req-body[4]           KDC-REQ-BODY
    }

    PA-DATA ::=        SEQUENCE {
               padata-type[1]        INTEGER,
               padata-value[2]       OCTET STRING,
                             -- might be encoded AP-REQ
    }

    KDC-REQ-BODY ::=   SEQUENCE {
                kdc-options[0]       KDCOptions,
                cname[1]             PrincipalName OPTIONAL,
                             -- Used only in AS-REQ
                realm[2]             Realm, -- Server's realm
                             -- Also client's in AS-REQ
                sname[3]             PrincipalName OPTIONAL,
                from[4]              KerberosTime OPTIONAL,
                till[5]              KerberosTime,
                rtime[6]             KerberosTime OPTIONAL,
                nonce[7]             INTEGER,
                etype[8]             SEQUENCE OF INTEGER, -- EncryptionType,
                             -- in preference order
                addresses[9]         HostAddresses OPTIONAL,
                enc-authorization-data[10]   EncryptedData OPTIONAL,
                             -- Encrypted AuthorizationData encoding
                additional-tickets[11]       SEQUENCE OF Ticket OPTIONAL
    }

The fields in this message are:

pvno

  This field is included in each message, and specifies the protocol version number. This document specifies protocol version 5.

msg-type

  This field indicates the type of a protocol message. It will almost always be the same as the application identifier associated with a message. It is included to make the identifier more readily accessible to the application. For the KDC-REQ message, this type will be KRB_AS_REQ or KRB_TGS_REQ.

padata

  The padata (pre-authentication data) field contains a of authentication information which may be needed before credentials can be issued or decrypted. In the case of requests for additional tickets (KRB_TGS_REQ), this field will include an element with padata-type of PA-TGS-REQ and data of an authentication header (ticket-granting ticket and authenticator). The checksum in the authenticator (which must be collisionproof) is to be computed over the KDC-REQ-BODY encoding. In most requests for initial authentication (KRB_AS_REQ) and most replies (KDC-REP), the padata field will be left out.

  This field may also contain information needed by certain extensions to the Kerberos protocol. For example, it might be used to initially verify the identity of a client before any response is returned. This is accomplished with a padata field with padata-type equal to PA-ENC-TIMESTAMP and padata-value defined as follows:

         padata-type     ::= PA-ENC-TIMESTAMP
         padata-value    ::= EncryptedData -- PA-ENC-TS-ENC

         PA-ENC-TS-ENC   ::= SEQUENCE {
                 patimestamp[0]               KerberosTime, -- client's time
                 pausec[1]                    INTEGER OPTIONAL
         }

  with patimestamp containing the client's time and pausec containing 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 sequence, encrypted using the client's secret key.

  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 "smartcards" with Kerberos. The details of such extensions are beyond the scope of this specification. See [10] for additional uses of this field.

padata-type

  The padata-type element of the padata field 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.

req-body

  This field is a placeholder delimiting the extent of the remaining fields. If a checksum is to be calculated over the request, it is calculated over an encoding of the KDC- REQ-BODY sequence which is enclosed within the req-body field.

kdc-options

  This field appears in the KRB_AS_REQ and KRB_TGS_REQ requests to the KDC and indicates the flags that the client wants set on the tickets as well as other information that is to modify the behavior of the KDC. Where appropriate, the name of an option may be the same as the flag that is set by that option. Although in most case, the bit in the options field will be the same as that in the flags field, this is not guaranteed, so it is not acceptable to simply copy the options field to the flags field. There are various checks that must be made before honoring an option anyway.

  The kdc_options field is a bit-field, where the selected options are indicated by the bit being set (1), and the unselected options and reserved fields being reset (0). The encoding of the bits is specified in section 5.2. The options are described in more detail above in section 2. The meanings of the options are:

       Bit(s)  Name         Description

       0       RESERVED     Reserved for future expansion of this
                            field.

       1       FORWARDABLE  The FORWARDABLE option indicates that
                            the ticket to be issued is to have its
                            forwardable flag set.  It may only be
                            set on the initial request, or in a
                            subsequent request if the ticket-
                            granting ticket on which it is based
                            is also forwardable.

       2       FORWARDED    The FORWARDED option is only specified
                            in a request to the ticket-granting
                            server and will only be honored if the
                            ticket-granting ticket in the request
                            has its FORWARDABLE bit set.  This
                            option indicates that this is a
                            request for forwarding. The
                            address(es) of the host from which the
                            resulting ticket is to be valid are
                            included in the addresses field of the
                            request.

       3       PROXIABLE    The PROXIABLE option indicates that
                            the ticket to be issued is to have its
                            proxiable flag set. It may only be set
                            on the initial request, or in a
                            subsequent request if the ticket-
                            granting ticket on which it is based
                            is also proxiable.

       4       PROXY        The PROXY option indicates that this
                            is a request for a proxy.  This option
                            will only be honored if the ticket-
                            granting ticket in the request has its
                            PROXIABLE bit set.  The address(es) of
                            the host from which the resulting
                            ticket is to be valid are included in
                            the addresses field of the request.

       5       ALLOW-POSTDATE The ALLOW-POSTDATE option indicates
                            that the ticket to be issued is to
                            have its MAY-POSTDATE flag set.  It
                            may only be set on the initial
                            request, or in a subsequent request if
                            the ticket-granting ticket on which it
                            is based also has its MAY-POSTDATE
                            flag set.

       6       POSTDATED    The POSTDATED option indicates that
                            this is a request for a postdated
                            ticket.  This option will only be
                            honored if the ticket-granting ticket
                            on which it is based has its MAY-
                            POSTDATE flag set.  The resulting
                            ticket will also have its INVALID flag
                            set, and that flag may be reset by a
                            subsequent request to the KDC after
                            the starttime in the ticket has been
                            reached.

       7       UNUSED       This option is presently unused.

       8       RENEWABLE    The RENEWABLE option indicates that
                            the ticket to be issued is to have its
                            RENEWABLE flag set.  It may only be
                            set on the initial request, or when
                            the ticket-granting ticket on which
                            the request is based is also
                            renewable.  If this option is
                            requested, then the rtime field in the
                            request contains the desired absolute
                            expiration time for the ticket.

       9-26    RESERVED     Reserved for future use.

       27      RENEWABLE-OK The RENEWABLE-OK option indicates that
                            a renewable ticket will be acceptable
                            if a ticket with the requested life
                            cannot otherwise be provided.  If a
                            ticket with the requested life cannot
                            be provided, then a renewable ticket
                            may be issued with a renew-till equal
                            to the the requested endtime.  The
                            value of the renew-till field may
                            still be limited by local limits, or
                            limits selected by the individual
                            principal or server.

       28      ENC-TKT-IN-SKEY This option is used only by the
                            ticket-granting service.  The ENC-
                            TKT-IN-SKEY option indicates that the
                            ticket for the end server is to be
                            encrypted in the session key from the
                            additional ticket-granting ticket
                            provided.

       29      RESERVED     Reserved for future use.

       30      RENEW        This option is used only by the
                            ticket-granting service.  The RENEW
                            option indicates that the present
                            request is for a renewal.  The ticket
                            provided is encrypted in the secret
                            key for the server on which it is
                            valid.  This option will only be
                            honored if the ticket to be renewed
                            has its RENEWABLE flag set and if the
                            time in its renew till field has not
                            passed.  The ticket to be renewed is
                            passed in the padata field as part of
                            the authentication header.

       31      VALIDATE     This option is used only by the
                            ticket-granting service.  The VALIDATE
                            option indicates that the request is
                            to validate a postdated ticket.  It
                            will only be honored if the ticket
                            presented is postdated, presently has
                            its INVALID flag set, and would be
                            otherwise usable at this time.  A
                            ticket cannot be validated before its
                            starttime.  The ticket presented for
                            validation is encrypted in the key of
                            the server for which it is valid and
                            is passed in the padata field as part
                            of the authentication header.

cname and sname

  These fields are the same as those described for the ticket in section 5.3.1. sname may only be absent when the ENC-TKT-IN-SKEY option is specified. If absent, the name of the server is taken from the name of the client in the ticket passed as additional-tickets.

enc-authorization-data

  The enc-authorization-data, if present (and it can only be present in the TGS_REQ form), is an encoding of the desired authorization-data encrypted under the sub- session key if present in the Authenticator, or alternatively from the session key in the ticket-granting ticket, both from the padata field in the KRB_AP_REQ.

realm

  This field specifies the realm part of the server's principal identifier. In the AS exchange, this is also the realm part of the client's principal identifier.

from

  This field is included in the KRB_AS_REQ and KRB_TGS_REQ ticket requests when the requested ticket is to be postdated. It specifies the desired start time for the requested ticket.

till

  This field contains the expiration date requested by the client in a ticket request.

rtime

  This field is the requested renew-till time sent from a client to the KDC in a ticket request. It is optional.

nonce

  This field is part of the KDC request and response. It it intended to hold a random number generated by the client. If the same number is included in the encrypted response from the KDC, it provides evidence that the response is fresh and has not been replayed by an attacker. Nonces must never be re-used. Ideally, it should be gen erated randomly, but if the correct time is known, it may suffice (Note, however, that if the time is used as the nonce, one must make sure that the workstation time is monotonically increasing. If the time is ever reset backwards, there is a small, but finite, probability that a nonce will be reused.).

etype

  This field specifies the desired encryption algorithm to be used in the response.

addresses

  This field is included in the initial request for tickets, and optionally included in requests for additional tickets from the ticket-granting server. It specifies the addresses from which the requested ticket is to be valid. Normally it includes the addresses for the client's host. If a proxy is requested, this field will contain other addresses. The contents of this field are usually copied by the KDC into the caddr field of the resulting ticket.

additional-tickets

  Additional tickets may be optionally included in a request to the ticket-granting server. If the ENC-TKT-IN- SKEY option has been specified, then the session key from the additional ticket will be used in place of the server's key to encrypt the new ticket. If more than one option which requires additional tickets has been specified, then the additional tickets are used in the order specified by the ordering of the options bits (see kdc-options, above).

The application code will be either ten (10) or twelve (12) depending on whether the request is for an initial ticket (AS-REQ) or for an additional ticket (TGS-REQ).

The optional fields (addresses, authorization-data and additional- tickets) are only included if necessary to perform the operation specified in the kdc-options field.

It should be noted that in KRB_TGS_REQ, the protocol version number appears twice and two different message types appear: the KRB_TGS_REQ message contains these fields as does the authentication header (KRB_AP_REQ) that is passed in the padata field.

Next: 5.4.2. KRB_KDC_REP definition

Connected: An Internet Encyclopedia
RFC 1510 - 5.4.1. KRB_KDC_REQ definition