blank.gif (43 bytes)

Church Of The
Swimming Elephant

Search:
5.4.1. KRB_KDC_REQ definition Connected: An Internet Encyclopedia
5.4.1. KRB_KDC_REQ definition

Up: 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

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
5.4.1. KRB_KDC_REQ definition

Cotse.Net

Protect yourself from cyberstalkers, identity thieves, and those who would snoop on you.
Stop spam from invading your inbox without losing the mail you want. We give you more control over your e-mail than any other service.
Block popups, ads, and malicious scripts while you surf the net through our anonymous proxies.
Participate in Usenet, host your web files, easily send anonymous messages, and more, much more.
All private, all encrypted, all secure, all in an easy to use service, and all for only $5.95 a month!

Service Details

 
.
www.cotse.com
Have you gone to church today?
.
All pages ©1999, 2000, 2001, 2002, 2003 Church of the Swimming Elephant unless otherwise stated
Church of the Swimming Elephant©1999, 2000, 2001, 2002, 2003 Cotse.com.
Cotse.com is a wholly owned subsidiary of Packetderm, LLC.

Packetderm, LLC
210 Park Ave #308
Worcester, MA 01609