tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 1510

 
 
 

The Kerberos Network Authentication Service (V5)

Part 3 of 4, p. 49 to 73
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 49 
5.4.  Specifications for the AS and TGS exchanges

   This section specifies the format of the messages used in exchange
   between the client and the Kerberos server.  The format of possible
   error messages appears in section 5.9.1.

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,

Top      Up      ToC       Page 50 
            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
   }

Top      Up      ToC       Page 51 
             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:

Top      Up      ToC       Page 52 
             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

Top      Up      ToC       Page 53 
                                  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

Top      Up      ToC       Page 54 
                                  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.

Top      Up      ToC       Page 55 
   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).

Top      Up      ToC       Page 56 
   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.

5.4.2. KRB_KDC_REP definition

   The KRB_KDC_REP message format is used for the reply from the KDC for
   either an initial (AS) request or a subsequent (TGS) request.  There
   is no message type for KRB_KDC_REP.  Instead, the type will be either
   KRB_AS_REP or KRB_TGS_REP.  The key used to encrypt the ciphertext
   part of the reply depends on the message type.  For KRB_AS_REP, the
   ciphertext is encrypted in the client's secret key, and the client's
   key version number is included in the key version number for the
   encrypted data.  For KRB_TGS_REP, the ciphertext is encrypted in the
   sub-session key from the Authenticator, or if absent, the session key
   from the ticket-granting ticket used in the request.  In that case,
   no version number will be present in the EncryptedData sequence.

   The KRB_KDC_REP message contains the following fields:

   AS-REP ::=    [APPLICATION 11] KDC-REP
   TGS-REP ::=   [APPLICATION 13] KDC-REP

   KDC-REP ::=   SEQUENCE {
                 pvno[0]                    INTEGER,
                 msg-type[1]                INTEGER,
                 padata[2]                  SEQUENCE OF PA-DATA OPTIONAL,
                 crealm[3]                  Realm,
                 cname[4]                   PrincipalName,
                 ticket[5]                  Ticket,
                 enc-part[6]                EncryptedData
   }

   EncASRepPart ::=    [APPLICATION 25[25]] EncKDCRepPart
   EncTGSRepPart ::=   [APPLICATION 26] EncKDCRepPart

   EncKDCRepPart ::=   SEQUENCE {
               key[0]                       EncryptionKey,
               last-req[1]                  LastReq,

Top      Up      ToC       Page 57 
               nonce[2]                     INTEGER,
               key-expiration[3]            KerberosTime OPTIONAL,
               flags[4]                     TicketFlags,
               authtime[5]                  KerberosTime,
               starttime[6]                 KerberosTime OPTIONAL,
               endtime[7]                   KerberosTime,
               renew-till[8]                KerberosTime OPTIONAL,
               srealm[9]                    Realm,
               sname[10]                    PrincipalName,
               caddr[11]                    HostAddresses OPTIONAL
   }

   NOTE: In EncASRepPart, the application code in the encrypted
         part of a message provides an additional check that
         the message was decrypted properly.

   pvno and msg-type These fields are described above in section 5.4.1.
             msg-type is either KRB_AS_REP or KRB_TGS_REP.

   padata    This field is described in detail in section 5.4.1.  One
             possible use for this field is to encode an alternate
             "mix-in" string to be used with a string-to-key algorithm
             (such as is described in section 6.3.2). This ability is
             useful to ease transitions if a realm name needs to change
             (e.g., when a company is acquired); in such a case all
             existing password-derived entries in the KDC database would
             be flagged as needing a special mix-in string until the
             next password change.

   crealm, cname, srealm and sname These fields are the same as those
             described for the ticket in section 5.3.1.

   ticket    The newly-issued ticket, from section 5.3.1.

   enc-part  This field is a place holder for the ciphertext and related
             information that forms the encrypted part of a message.
             The description of the encrypted part of the message
             follows each appearance of this field.  The encrypted part
             is encoded as described in section 6.1.

   key       This field is the same as described for the ticket in
             section 5.3.1.

   last-req  This field is returned by the KDC and specifies the time(s)
             of the last request by a principal.  Depending on what
             information is available, this might be the last time that
             a request for a ticket-granting ticket was made, or the
             last time that a request based on a ticket-granting ticket

Top      Up      ToC       Page 58 
             was successful.  It also might cover all servers for a
             realm, or just the particular server. Some implementations
             may display this information to the user to aid in
             discovering unauthorized use of one's identity.  It is
             similar in spirit to the last login time displayed when
             logging into timesharing systems.

   nonce     This field is described above in section 5.4.1.

   key-expiration The key-expiration field is part of the response from
             the KDC and specifies the time that the client's secret key
             is due to expire.  The expiration might be the result of
             password aging or an account expiration.  This field will
             usually be left out of the TGS reply since the response to
             the TGS request is encrypted in a session key and no client
             information need be retrieved from the KDC database.  It is
             up to the application client (usually the login program) to
             take appropriate action (such as notifying the user) if the
             expira    tion time is imminent.

   flags, authtime, starttime, endtime, renew-till and caddr These
             fields are duplicates of those found in the encrypted
             portion of the attached ticket (see section 5.3.1),
             provided so the client may verify they match the intended
             request and to assist in proper ticket caching.  If the
             message is of type KRB_TGS_REP, the caddr field will only
             be filled in if the request was for a proxy or forwarded
             ticket, or if the user is substituting a subset of the
             addresses from the ticket granting ticket.  If the client-
             requested addresses are not present or not used, then the
             addresses contained in the ticket will be the same as those
             included in the ticket-granting ticket.

5.5.  Client/Server (CS) message specifications

   This section specifies the format of the messages used for the
   authentication of the client to the application server.

5.5.1. KRB_AP_REQ definition

   The KRB_AP_REQ message contains the Kerberos protocol version number,
   the message type KRB_AP_REQ, an options field to indicate any options
   in use, and the ticket and authenticator themselves.  The KRB_AP_REQ
   message is often referred to as the "authentication header".

   AP-REQ ::=      [APPLICATION 14] SEQUENCE {
                   pvno[0]                       INTEGER,
                   msg-type[1]                   INTEGER,

Top      Up      ToC       Page 59 
                   ap-options[2]                 APOptions,
                   ticket[3]                     Ticket,
                   authenticator[4]              EncryptedData
   }

   APOptions ::=   BIT STRING {
                   reserved(0),
                   use-session-key(1),
                   mutual-required(2)
   }

   pvno and msg-type These fields are described above in section 5.4.1.
             msg-type is KRB_AP_REQ.

   ap-options This field appears in the application request (KRB_AP_REQ)
             and affects the way the request is processed.  It 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 meanings of the options are:

             Bit(s)  Name           Description

             0       RESERVED       Reserved for future expansion of
                                  this field.

             1       USE-SESSION-KEYThe USE-SESSION-KEY option indicates
                                  that the ticket the client is
                                  presenting to a server is encrypted in
                                  the session key from the server's
                                  ticket-granting ticket. When this
                                  option is not specified, the ticket is
                                  encrypted in the server's secret key.

             2       MUTUAL-REQUIREDThe MUTUAL-REQUIRED option tells the
                                  server that the client requires mutual
                                  authentication, and that it must
                                  respond with a KRB_AP_REP message.

             3-31    RESERVED       Reserved for future use.

   ticket    This field is a ticket authenticating the client to the
             server.

   authenticator This contains the authenticator, which includes the
             client's choice of a subkey.  Its encoding is described in
             section 5.3.2.

Top      Up      ToC       Page 60 
5.5.2.  KRB_AP_REP definition

   The KRB_AP_REP message contains the Kerberos protocol version number,
   the message type, and an encrypted timestamp. The message is sent in
   in response to an application request (KRB_AP_REQ) where the mutual
   authentication option has been selected in the ap-options field.

   AP-REP ::=         [APPLICATION 15] SEQUENCE {
              pvno[0]                   INTEGER,
              msg-type[1]               INTEGER,
              enc-part[2]               EncryptedData
   }

   EncAPRepPart ::=   [APPLICATION 27]     SEQUENCE {
              ctime[0]                  KerberosTime,
              cusec[1]                  INTEGER,
              subkey[2]                 EncryptionKey OPTIONAL,
              seq-number[3]             INTEGER OPTIONAL
   }

   NOTE: in EncAPRepPart, the application code in the encrypted part of
   a message provides an additional check that the message was decrypted
   properly.

   The encoded EncAPRepPart is encrypted in the shared session key of
   the ticket.  The optional subkey field can be used in an
   application-arranged negotiation to choose a per association session
   key.

   pvno and msg-type These fields are described above in section 5.4.1.
             msg-type is KRB_AP_REP.

   enc-part  This field is described above in section 5.4.2.

   ctime     This field contains the current time on the client's host.

   cusec     This field contains the microsecond part of the client's
             timestamp.

   subkey    This field contains an encryption key which is to be used
             to protect this specific application session.  See section
             3.2.6 for specifics on how this field is used to negotiate
             a key.  Unless an application specifies otherwise, if this
             field is left out, the sub-session key from the
             authenticator, or if also left out, the session key from
             the ticket will be used.

Top      Up      ToC       Page 61 
5.5.3. Error message reply

   If an error occurs while processing the application request, the
   KRB_ERROR message will be sent in response.  See section 5.9.1 for
   the format of the error message.  The cname and crealm fields may be
   left out if the server cannot determine their appropriate values from
   the corresponding KRB_AP_REQ message.  If the authenticator was
   decipherable, the ctime and cusec fields will contain the values from
   it.

5.6.  KRB_SAFE message specification

   This section specifies the format of a message that can be used by
   either side (client or server) of an application to send a tamper-
   proof message to its peer. It presumes that a session key has
   previously been exchanged (for example, by using the
   KRB_AP_REQ/KRB_AP_REP messages).

5.6.1. KRB_SAFE definition

   The KRB_SAFE message contains user data along with a collision-proof
   checksum keyed with the session key.  The message fields are:

   KRB-SAFE ::=        [APPLICATION 20] SEQUENCE {
               pvno[0]               INTEGER,
               msg-type[1]           INTEGER,
               safe-body[2]          KRB-SAFE-BODY,
               cksum[3]              Checksum
   }

   KRB-SAFE-BODY ::=   SEQUENCE {
               user-data[0]          OCTET STRING,
               timestamp[1]          KerberosTime OPTIONAL,
               usec[2]               INTEGER OPTIONAL,
               seq-number[3]         INTEGER OPTIONAL,
               s-address[4]          HostAddress,
               r-address[5]          HostAddress OPTIONAL
   }

   pvno and msg-type These fields are described above in section 5.4.1.
             msg-type is KRB_SAFE.

   safe-body This field is a placeholder for the body of the KRB-SAFE
             message.  It is to be encoded separately and then have the
             checksum computed over it, for use in the cksum field.

   cksum     This field contains the checksum of the application data.
             Checksum details are described in section 6.4.  The

Top      Up      ToC       Page 62 
             checksum is computed over the encoding of the KRB-SAFE-BODY
             sequence.

   user-data This field is part of the KRB_SAFE and KRB_PRIV messages
             and contain the application specific data that is being
             passed from the sender to the recipient.

   timestamp This field is part of the KRB_SAFE and KRB_PRIV messages.
             Its contents are the current time as known by the sender of
             the message. By checking the timestamp, the recipient of
             the message is able to make sure that it was recently
             generated, and is not a replay.

   usec      This field is part of the KRB_SAFE and KRB_PRIV headers.
             It contains the microsecond part of the timestamp.

   seq-number This field is described above in section 5.3.2.

   s-address This field specifies the address in use by the sender of
             the message.

   r-address This field specifies the address in use by the recipient of
             the message.  It may be omitted for some uses (such as
             broadcast protocols), but the recipient may arbitrarily
             reject such messages.  This field along with s-address can
             be used to help detect messages which have been incorrectly
             or maliciously delivered to the wrong recipient.

5.7.  KRB_PRIV message specification

   This section specifies the format of a message that can be used by
   either side (client or server) of an application to securely and
   privately send a message to its peer.  It presumes that a session key
   has previously been exchanged (for example, by using the
   KRB_AP_REQ/KRB_AP_REP messages).

5.7.1. KRB_PRIV definition

   The KRB_PRIV message contains user data encrypted in the Session Key.
   The message fields are:

   KRB-PRIV ::=         [APPLICATION 21] SEQUENCE {
                pvno[0]                   INTEGER,
                msg-type[1]               INTEGER,
                enc-part[3]               EncryptedData
   }

Top      Up      ToC       Page 63 
   EncKrbPrivPart ::=   [APPLICATION 28] SEQUENCE {
                user-data[0]              OCTET STRING,
                timestamp[1]              KerberosTime OPTIONAL,
                usec[2]                   INTEGER OPTIONAL,
                seq-number[3]             INTEGER OPTIONAL,
                s-address[4]              HostAddress, -- sender's addr
                r-address[5]              HostAddress OPTIONAL
                                                      -- recip's addr
   }

   NOTE: In EncKrbPrivPart, the application code in the encrypted part
   of a message provides an additional check that the message was
   decrypted properly.

   pvno and msg-type These fields are described above in section 5.4.1.
             msg-type is KRB_PRIV.

   enc-part  This field holds an encoding of the EncKrbPrivPart sequence
             encrypted under the session key (If supported by the
             encryption method in use, an initialization vector may be
             passed to the encryption procedure, in order to achieve
             proper cipher chaining.  The initialization vector might
             come from the last block of the ciphertext from the
             previous KRB_PRIV message, but it is the application's
             choice whether or not to use such an initialization vector.
             If left out, the default initialization vector for the
             encryption algorithm will be used.).  This encrypted
             encoding is used for the enc-part field of the KRB-PRIV
             message.  See section 6 for the format of the ciphertext.

   user-data, timestamp, usec, s-address and r-address These fields are
             described above in section 5.6.1.

   seq-number This field is described above in section 5.3.2.

5.8.  KRB_CRED message specification

   This section specifies the format of a message that can be used to
   send Kerberos credentials from one principal to another.  It is
   presented here to encourage a common mechanism to be used by
   applications when forwarding tickets or providing proxies to
   subordinate servers.  It presumes that a session key has already been
   exchanged perhaps by using the KRB_AP_REQ/KRB_AP_REP messages.

5.8.1. KRB_CRED definition

   The KRB_CRED message contains a sequence of tickets to be sent and
   information needed to use the tickets, including the session key from

Top      Up      ToC       Page 64 
   each.  The information needed to use the tickets is encryped under an
   encryption key previously exchanged.  The message fields are:

   KRB-CRED         ::= [APPLICATION 22]   SEQUENCE {
                    pvno[0]                INTEGER,
                    msg-type[1]            INTEGER, -- KRB_CRED
                    tickets[2]             SEQUENCE OF Ticket,
                    enc-part[3]            EncryptedData
   }

   EncKrbCredPart   ::= [APPLICATION 29]   SEQUENCE {
                    ticket-info[0]         SEQUENCE OF KrbCredInfo,
                    nonce[1]               INTEGER OPTIONAL,
                    timestamp[2]           KerberosTime OPTIONAL,
                    usec[3]                INTEGER OPTIONAL,
                    s-address[4]           HostAddress OPTIONAL,
                    r-address[5]           HostAddress OPTIONAL
   }

   KrbCredInfo      ::=                    SEQUENCE {
                    key[0]                 EncryptionKey,
                    prealm[1]              Realm OPTIONAL,
                    pname[2]               PrincipalName OPTIONAL,
                    flags[3]               TicketFlags OPTIONAL,
                    authtime[4]            KerberosTime OPTIONAL,
                    starttime[5]           KerberosTime OPTIONAL,
                    endtime[6]             KerberosTime OPTIONAL
                    renew-till[7]          KerberosTime OPTIONAL,
                    srealm[8]              Realm OPTIONAL,
                    sname[9]               PrincipalName OPTIONAL,
                    caddr[10]              HostAddresses OPTIONAL
   }


   pvno and msg-type These fields are described above in section 5.4.1.
             msg-type is KRB_CRED.

   tickets
               These are the tickets obtained from the KDC specifically
             for use by the intended recipient.  Successive tickets are
             paired with the corresponding KrbCredInfo sequence from the
             enc-part of the KRB-CRED message.

   enc-part  This field holds an encoding of the EncKrbCredPart sequence
             encrypted under the session key shared between the sender
             and the intended recipient.  This encrypted encoding is
             used for the enc-part field of the KRB-CRED message.  See
             section 6 for the format of the ciphertext.

Top      Up      ToC       Page 65 
   nonce     If practical, an application may require the inclusion of a
             nonce generated by the recipient of the message. If the
             same value is included as the nonce in the message, it
             provides evidence that the message is fresh and has not
             been replayed by an attacker.  A nonce must never be re-
             used; it should be generated randomly by the recipient of
             the message and provided to the sender of the mes  sage in
             an application specific manner.

   timestamp and usec These fields specify the time that the KRB-CRED
             message was generated.  The time is used to provide
             assurance that the message is fresh.

   s-address and r-address These fields are described above in section
             5.6.1.  They are used optionally to provide additional
             assurance of the integrity of the KRB-CRED message.

   key       This field exists in the corresponding ticket passed by the
             KRB-CRED message and is used to pass the session key from
             the sender to the intended recipient.  The field's encoding
             is described in section 6.2.

   The following fields are optional.   If present, they can be
   associated with the credentials in the remote ticket file.  If left
   out, then it is assumed that the recipient of the credentials already
   knows their value.

   prealm and pname The name and realm of the delegated principal
             identity.

   flags, authtime,  starttime,  endtime, renew-till,  srealm, sname,
             and caddr These fields contain the values of the
             corresponding fields from the ticket found in the ticket
             field.  Descriptions of the fields are identical to the
             descriptions in the KDC-REP message.

5.9.  Error message specification

   This section specifies the format for the KRB_ERROR message.  The
   fields included in the message are intended to return as much
   information as possible about an error.  It is not expected that all
   the information required by the fields will be available for all
   types of errors.  If the appropriate information is not available
   when the message is composed, the corresponding field will be left
   out of the message.

   Note that since the KRB_ERROR message is not protected by any
   encryption, it is quite possible for an intruder to synthesize or

Top      Up      ToC       Page 66 
   modify such a message.  In particular, this means that the client
   should not use any fields in this message for security-critical
   purposes, such as setting a system clock or generating a fresh
   authenticator.  The message can be useful, however, for advising a
   user on the reason for some failure.

5.9.1. KRB_ERROR definition

   The KRB_ERROR message consists of the following fields:

   KRB-ERROR ::=   [APPLICATION 30] SEQUENCE {
                   pvno[0]               INTEGER,
                   msg-type[1]           INTEGER,
                   ctime[2]              KerberosTime OPTIONAL,
                   cusec[3]              INTEGER OPTIONAL,
                   stime[4]              KerberosTime,
                   susec[5]              INTEGER,
                   error-code[6]         INTEGER,
                   crealm[7]             Realm OPTIONAL,
                   cname[8]              PrincipalName OPTIONAL,
                   realm[9]              Realm, -- Correct realm
                   sname[10]             PrincipalName, -- Correct name
                   e-text[11]            GeneralString OPTIONAL,
                   e-data[12]            OCTET STRING OPTIONAL
   }

   pvno and msg-type These fields are described above in section 5.4.1.
             msg-type is KRB_ERROR.

   ctime     This field is described above in section 5.4.1.

   cusec     This field is described above in section 5.5.2.

   stime     This field contains the current time on the server.  It is
             of type KerberosTime.

   susec     This field contains the microsecond part of the server's
             timestamp.  Its value ranges from 0 to 999. It appears
             along with stime. The two fields are used in conjunction to
             specify a reasonably accurate timestamp.

   error-code This field contains the error code returned by Kerberos or
             the server when a request fails.  To interpret the value of
             this field see the list of error codes in section 8.
             Implementations are encouraged to provide for national
             language support in the display of error messages.

   crealm, cname, srealm and sname These fields are described above in

Top      Up      ToC       Page 67 
             section 5.3.1.

   e-text    This field contains additional text to help explain the
             error code associated with the failed request (for example,
             it might include a principal name which was unknown).

   e-data    This field contains additional data about the error for use
             by the application to help it recover from or handle the
             error.  If the errorcode is KDC_ERR_PREAUTH_REQUIRED, then
             the e-data field will contain an encoding of a sequence of
             padata fields, each corresponding to an acceptable pre-
             authentication method and optionally containing data for
             the method:

      METHOD-DATA ::=    SEQUENCE of PA-DATA

   If the error-code is KRB_AP_ERR_METHOD, then the e-data field will
   contain an encoding of the following sequence:

      METHOD-DATA ::=    SEQUENCE {
                         method-type[0]   INTEGER,
                         method-data[1]   OCTET STRING OPTIONAL
       }

   method-type will indicate the required alternate method; method-data
   will contain any required additional information.

6.  Encryption and Checksum Specifications

   The Kerberos protocols described in this document are designed to use
   stream encryption ciphers, which can be simulated using commonly
   available block encryption ciphers, such as the Data Encryption
   Standard [11], in conjunction with block chaining and checksum
   methods [12].  Encryption is used to prove the identities of the
   network entities participating in message exchanges.  The Key
   Distribution Center for each realm is trusted by all principals
   registered in that realm to store a secret key in confidence.  Proof
   of knowledge of this secret key is used to verify the authenticity of
   a principal.

   The KDC uses the principal's secret key (in the AS exchange) or a
   shared session key (in the TGS exchange) to encrypt responses to
   ticket requests; the ability to obtain the secret key or session key
   implies the knowledge of the appropriate keys and the identity of the
   KDC. The ability of a principal to decrypt the KDC response and
   present a Ticket and a properly formed Authenticator (generated with
   the session key from the KDC response) to a service verifies the
   identity of the principal; likewise the ability of the service to

Top      Up      ToC       Page 68 
   extract the session key from the Ticket and prove its knowledge
   thereof in a response verifies the identity of the service.

   The Kerberos protocols generally assume that the encryption used is
   secure from cryptanalysis; however, in some cases, the order of
   fields in the encrypted portions of messages are arranged to minimize
   the effects of poorly chosen keys.  It is still important to choose
   good keys.  If keys are derived from user-typed passwords, those
   passwords need to be well chosen to make brute force attacks more
   difficult.  Poorly chosen keys still make easy targets for intruders.

   The following sections specify the encryption and checksum mechanisms
   currently defined for Kerberos.  The encodings, chaining, and padding
   requirements for each are described.  For encryption methods, it is
   often desirable to place random information (often referred to as a
   confounder) at the start of the message.  The requirements for a
   confounder are specified with each encryption mechanism.

   Some encryption systems use a block-chaining method to improve the
   the security characteristics of the ciphertext.  However, these
   chaining methods often don't provide an integrity check upon
   decryption.  Such systems (such as DES in CBC mode) must be augmented
   with a checksum of the plaintext which can be verified at decryption
   and used to detect any tampering or damage.  Such checksums should be
   good at detecting burst errors in the input.  If any damage is
   detected, the decryption routine is expected to return an error
   indicating the failure of an integrity check. Each encryption type is
   expected to provide and verify an appropriate checksum. The
   specification of each encryption method sets out its checksum
   requirements.

   Finally, where a key is to be derived from a user's password, an
   algorithm for converting the password to a key of the appropriate
   type is included.  It is desirable for the string to key function to
   be one-way, and for the mapping to be different in different realms.
   This is important because users who are registered in more than one
   realm will often use the same password in each, and it is desirable
   that an attacker compromising the Kerberos server in one realm not
   obtain or derive the user's key in another.

   For a discussion of the integrity characteristics of the candidate
   encryption and checksum methods considered for Kerberos, the the
   reader is referred to [13].

6.1.  Encryption Specifications

   The following ASN.1 definition describes all encrypted messages.  The
   enc-part field which appears in the unencrypted part of messages in

Top      Up      ToC       Page 69 
   section 5 is a sequence consisting of an encryption type, an optional
   key version number, and the ciphertext.

   EncryptedData ::=   SEQUENCE {
                       etype[0]     INTEGER, -- EncryptionType
                       kvno[1]      INTEGER OPTIONAL,
                       cipher[2]    OCTET STRING -- ciphertext
   }

   etype     This field identifies which encryption algorithm was used
             to encipher the cipher.  Detailed specifications for
             selected encryption types appear later in this section.

   kvno      This field contains the version number of the key under
             which data is encrypted.  It is only present in messages
             encrypted under long lasting keys, such as principals'
             secret keys.

   cipher    This field contains the enciphered text, encoded as an
             OCTET STRING.

   The cipher field is generated by applying the specified encryption
   algorithm to data composed of the message and algorithm-specific
   inputs.  Encryption mechanisms defined for use with Kerberos must
   take sufficient measures to guarantee the integrity of the plaintext,
   and we recommend they also take measures to protect against
   precomputed dictionary attacks.  If the encryption algorithm is not
   itself capable of doing so, the protections can often be enhanced by
   adding a checksum and a confounder.

   The suggested format for the data to be encrypted includes a
   confounder, a checksum, the encoded plaintext, and any necessary
   padding.  The msg-seq field contains the part of the protocol message
   described in section 5 which is to be encrypted.  The confounder,
   checksum, and padding are all untagged and untyped, and their length
   is exactly sufficient to hold the appropriate item.  The type and
   length is implicit and specified by the particular encryption type
   being used (etype).  The format for the data to be encrypted is
   described in the following diagram:

         +-----------+----------+-------------+-----+
         |confounder |   check  |   msg-seq   | pad |
         +-----------+----------+-------------+-----+

   The format cannot be described in ASN.1, but for those who prefer an
   ASN.1-like notation:

Top      Up      ToC       Page 70 
CipherText ::=   ENCRYPTED       SEQUENCE {
         confounder[0]   UNTAGGED OCTET STRING(conf_length)     OPTIONAL,
         check[1]        UNTAGGED OCTET STRING(checksum_length) OPTIONAL,
         msg-seq[2]      MsgSequence,
         pad             UNTAGGED OCTET STRING(pad_length) OPTIONAL
}

   In the above specification, UNTAGGED OCTET STRING(length) is the
   notation for an octet string with its tag and length removed.  It is
   not a valid ASN.1 type.  The tag bits and length must be removed from
   the confounder since the purpose of the confounder is so that the
   message starts with random data, but the tag and its length are
   fixed.  For other fields, the length and tag would be redundant if
   they were included because they are specified by the encryption type.

   One generates a random confounder of the appropriate length, placing
   it in confounder; zeroes out check; calculates the appropriate
   checksum over confounder, check, and msg-seq, placing the result in
   check; adds the necessary padding; then encrypts using the specified
   encryption type and the appropriate key.

   Unless otherwise specified, a definition of an encryption algorithm
   that specifies a checksum, a length for the confounder field, or an
   octet boundary for padding uses this ciphertext format (The ordering
   of the fields in the CipherText is important.  Additionally, messages
   encoded in this format must include a length as part of the msg-seq
   field.  This allows the recipient to verify that the message has not
   been truncated.  Without a length, an attacker could use a chosen
   plaintext attack to generate a message which could be truncated,
   while leaving the checksum intact.  Note that if the msg-seq is an
   encoding of an ASN.1 SEQUENCE or OCTET STRING, then the length is
   part of that encoding.). Those fields which are not specified will be
   omitted.

   In the interest of allowing all implementations using a particular
   encryption type to communicate with all others using that type, the
   specification of an encryption type defines any checksum that is
   needed as part of the encryption process.  If an alternative checksum
   is to be used, a new encryption type must be defined.

   Some cryptosystems require additional information beyond the key and
   the data to be encrypted. For example, DES, when used in cipher-
   block-chaining mode, requires an initialization vector.  If required,
   the description for each encryption type must specify the source of
   such additional information.

Top      Up      ToC       Page 71 
6.2.  Encryption Keys

   The sequence below shows the encoding of an encryption key:

          EncryptionKey ::=   SEQUENCE {
                              keytype[0]    INTEGER,
                              keyvalue[1]   OCTET STRING
          }

   keytype   This field specifies the type of encryption key that
             follows in the keyvalue field.  It will almost always
             correspond to the encryption algorithm used to generate the
             EncryptedData, though more than one algorithm may use the
             same type of key (the mapping is many to one).  This might
             happen, for example, if the encryption algorithm uses an
             alternate checksum algorithm for an integrity check, or a
             different chaining mechanism.

   keyvalue  This field contains the key itself, encoded as an octet
             string.

   All negative values for the  encryption key type are reserved for
   local use.  All non-negative values are reserved for officially
   assigned type fields and interpretations.

6.3.  Encryption Systems

6.3.1. The NULL Encryption System (null)

   If no encryption is in use, the encryption system is said to be the
   NULL encryption system.  In the NULL encryption system there is no
   checksum, confounder or padding.  The ciphertext is simply the
   plaintext.  The NULL Key is used by the null encryption system and is
   zero octets in length, with keytype zero (0).

6.3.2. DES in CBC mode with a CRC-32 checksum (des-cbc-crc)

   The des-cbc-crc encryption mode encrypts information under the Data
   Encryption Standard [11] using the cipher block chaining mode [12].
   A CRC-32 checksum (described in ISO 3309 [14]) is applied to the
   confounder and message sequence (msg-seq) and placed in the cksum
   field.  DES blocks are 8 bytes.  As a result, the data to be
   encrypted (the concatenation of confounder, checksum, and message)
   must be padded to an 8 byte boundary before encryption.  The details
   of the encryption of this data are identical to those for the des-
   cbc-md5 encryption mode.

   Note that, since the CRC-32 checksum is not collisionproof, an

Top      Up      ToC       Page 72 
   attacker could use a probabilistic chosenplaintext attack to generate
   a valid message even if a confounder is used [13]. The use of
   collision-proof checksums is recommended for environments where such
   attacks represent a significant threat.  The use of the CRC-32 as the
   checksum for ticket or authenticator is no longer mandated as an
   interoperability requirement for Kerberos Version 5 Specification 1
   (See section 9.1 for specific details).

6.3.3. DES in CBC mode with an MD4 checksum (des-cbc-md4)

   The des-cbc-md4 encryption mode encrypts information under the Data
   Encryption Standard [11] using the cipher block chaining mode [12].
   An MD4 checksum (described in [15]) is applied to the confounder and
   message sequence (msg-seq) and placed in the cksum field.  DES blocks
   are 8 bytes.  As a result, the data to be encrypted (the
   concatenation of confounder, checksum, and message) must be padded to
   an 8 byte boundary before encryption.  The details of the encryption
   of this data are identical to those for the descbc-md5 encryption
   mode.

6.3.4. DES in CBC mode with an MD5 checksum (des-cbc-md5)

   The des-cbc-md5 encryption mode encrypts information under the Data
   Encryption Standard [11] using the cipher block chaining mode [12].
   An MD5 checksum (described in [16]) is applied to the confounder and
   message sequence (msg-seq) and placed in the cksum field.  DES blocks
   are 8 bytes.  As a result, the data to be encrypted (the
   concatenation of confounder, checksum, and message) must be padded to
   an 8 byte boundary before encryption.

   Plaintext and DES ciphtertext are encoded as 8-octet blocks which are
   concatenated to make the 64-bit inputs for the DES algorithms.  The
   first octet supplies the 8 most significant bits (with the octet's
   MSbit used as the DES input block's MSbit, etc.), the second octet
   the next 8 bits, ..., and the eighth octet supplies the 8 least
   significant bits.

   Encryption under DES using cipher block chaining requires an
   additional input in the form of an initialization vector.  Unless
   otherwise specified, zero should be used as the initialization
   vector.  Kerberos' use of DES requires an 8-octet confounder.

   The DES specifications identify some "weak" and "semiweak" keys;
   those keys shall not be used for encrypting messages for use in
   Kerberos.  Additionally, because of the way that keys are derived for
   the encryption of checksums, keys shall not be used that yield "weak"
   or "semi-weak" keys when eXclusive-ORed with the constant
   F0F0F0F0F0F0F0F0.

Top      Up      ToC       Page 73 
   A DES key is 8 octets of data, with keytype one (1).  This consists
   of 56 bits of key, and 8 parity bits (one per octet).  The key is
   encoded as a series of 8 octets written in MSB-first order. The bits
   within the key are also encoded in MSB order.  For example, if the
   encryption key is:
   (B1,B2,...,B7,P1,B8,...,B14,P2,B15,...,B49,P7,B50,...,B56,P8) where
   B1,B2,...,B56 are the key bits in MSB order, and P1,P2,...,P8 are the
   parity bits, the first octet of the key would be B1,B2,...,B7,P1
   (with B1 as the MSbit).  [See the FIPS 81 introduction for
   reference.]

   To generate a DES key from a text string (password), the text string
   normally must have the realm and each component of the principal's
   name appended(In some cases, it may be necessary to use a different
   "mix-in" string for compatibility reasons; see the discussion of
   padata in section 5.4.2.), then padded with ASCII nulls to an 8 byte
   boundary.  This string is then fan-folded and eXclusive-ORed with
   itself to form an 8 byte DES key.  The parity is corrected on the
   key, and it is used to generate a DES CBC checksum on the initial
   string (with the realm and name appended).  Next, parity is corrected
   on the CBC checksum.  If the result matches a "weak" or "semiweak"
   key as described in the DES specification, it is eXclusive-ORed with
   the constant 00000000000000F0.  Finally, the result is returned as
   the key.  Pseudocode follows:

        string_to_key(string,realm,name) {
             odd = 1;
             s = string + realm;
             for(each component in name) {
                  s = s + component;
             }
             tempkey = NULL;
             pad(s); /* with nulls to 8 byte boundary */
             for(8byteblock in s) {
                  if(odd == 0)  {
                      odd = 1;
                      reverse(8byteblock)
                  }
                  else odd = 0;
                  tempkey = tempkey XOR 8byteblock;
             }
             fixparity(tempkey);
             key = DES-CBC-check(s,tempkey);
             fixparity(key);
             if(is_weak_key_key(key))
                  key = key XOR 0xF0;
             return(key);
        }


Next RFC Part