Connected: An Internet Encyclopedia
RFC 1510 - 3.2.4. Generation of a KRB_AP_REP message

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1510
Up: 3. Message Exchanges
Up: 3.2. The Client/Server Authentication Exchange
Prev: 3.2.3. Receipt of KRB_AP_REQ message
Next: 3.2.5. Receipt of KRB_AP_REP message

### 3.2.4. Generation of a KRB_AP_REP message

Typically, a client's request will include both the authentication information and its initial request in the same message, and the server need not explicitly reply to the KRB_AP_REQ. However, if mutual authentication (not only authenticating the client to the server, but also the server to the client) is being performed, the KRB_AP_REQ message will have MUTUAL-REQUIRED set in its ap-options field, and a KRB_AP_REP message is required in response. As with the error message, this message may be encapsulated in the application protocol if its "raw" form is not acceptable to the application's protocol. The timestamp and microsecond field used in the reply must be the client's timestamp and microsecond field (as provided in the authenticator). [Note: In the Kerberos version 4 protocol, the timestamp in the reply was the client's timestamp plus one. This is not necessary in version 5 because version 5 messages are formatted in such a way that it is not possible to create the reply by judicious message surgery (even in encrypted form) without knowledge of the appropriate encryption keys.] If a sequence number is to be included, it should be randomly chosen as described above for the authenticator. A subkey may be included if the server desires to negotiate a different subkey. The KRB_AP_REP message is encrypted in the session key extracted from the ticket. See section A.11 for pseudocode.

Next: 3.2.5. Receipt of KRB_AP_REP message

Connected: An Internet Encyclopedia
RFC 1510 - 3.2.4. Generation of a KRB_AP_REP message