3.1.3. Generation of KRB_AS_REP message
Connected: An Internet Encyclopedia
3.1.3. Generation of KRB_AS_REP message
Up:
Connected: An Internet Encyclopedia
Up:
Requests For Comments
Up:
RFC 1510
Up:
3. Message Exchanges
Up:
3.1. The Authentication Service Exchange
Prev: 3.1.2. Receipt of KRB_AS_REQ message
Next: 3.1.4. Generation of KRB_ERROR message
3.1.3. Generation of KRB_AS_REP message
3.1.3. Generation of KRB_AS_REP message
The authentication server looks up the client and server principals
named in the KRB_AS_REQ in its database, extracting their respective
keys. If required, the server pre-authenticates the request, and if
the pre-authentication check fails, an error message with the code
KDC_ERR_PREAUTH_FAILED is returned. If the server cannot accommodate
the requested encryption type, an error message with code
KDC_ERR_ETYPE_NOSUPP is returned. Otherwise it generates a "random"
session key ("Random" means that, among other things, it should be
impossible to guess the next session key based on knowledge of past
session keys. This can only be achieved in a pseudo-random number
generator if it is based on cryptographic principles. It would be
more desirable to use a truly random number generator, such as one
based on measurements of random physical phenomena.).
If the requested start time is absent or indicates a time in the
past, then the start time of the ticket is set to the authentication
server's current time. If it indicates a time in the future, but the
POSTDATED option has not been specified, then the error
KDC_ERR_CANNOT_POSTDATE is returned. Otherwise the requested start
time is checked against the policy of the local realm (the
administrator might decide to prohibit certain types or ranges of
postdated tickets), and if acceptable, the ticket's start time is set
as requested and the INVALID flag is set in the new ticket. The
postdated ticket must be validated before use by presenting it to the
KDC after the start time has been reached.
The expiration time of the ticket will be set to the minimum of the
following:
- The expiration time (endtime) requested in the KRB_AS_REQ
message.
- The ticket's start time plus the maximum allowable lifetime
associated with the client principal (the authentication
server's database includes a maximum ticket lifetime field
in each principal's record; see section 4).
- The ticket's start time plus the maximum allowable lifetime
associated with the server principal.
- The ticket's start time plus the maximum lifetime set by
the policy of the local realm.
If the requested expiration time minus the start time (as determined
above) is less than a site-determined minimum lifetime, an error
message with code KDC_ERR_NEVER_VALID is returned. If the requested
expiration time for the ticket exceeds what was determined as above,
and if the "RENEWABLE-OK" option was requested, then the "RENEWABLE"
flag is set in the new ticket, and the renew-till value is set as if
the "RENEWABLE" option were requested (the field and option names are
described fully in section 5.4.1). If the RENEWABLE option has been
requested or if the RENEWABLE-OK option has been set and a renewable
ticket is to be issued, then the renew-till field is set to the
minimum of:
- Its requested value.
- The start time of the ticket plus the minimum of the two
maximum renewable lifetimes associated with the principals'
database entries.
- The start time of the ticket plus the maximum renewable
lifetime set by the policy of the local realm.
The flags field of the new ticket will have the following options set
if they have been requested and if the policy of the local realm
allows: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE.
If the new ticket is postdated (the start time is in the future), its
INVALID flag will also be set.
If all of the above succeed, the server formats a KRB_AS_REP message
(see section 5.4.2), copying the addresses in the request into the
caddr of the response, placing any required pre-authentication data
into the padata of the response, and encrypts the ciphertext part in
the client's key using the requested encryption method, and sends it
to the client. See section A.2 for pseudocode.
Next: 3.1.4. Generation of KRB_ERROR message
Connected: An Internet Encyclopedia
3.1.3. Generation of KRB_AS_REP message
|